team-mgmt-service

Description

Team management service is a production ready and fully tested service that can be used as a template for a microservice development.

Keywords: microservice, kotlin, Hexagonal-Architecture, SOLID, Domain-Driven Design, functional-programming, Testing, Event-Driven Architecture, Domain-Events, Kafka, spring-boot, PostgreSQL, Transactional-outbox

Overview

Use-cases

• Create a team
• Add person as a team member
• Remove person as a team member

Use-case diagram

Example of how a use-case looks like:

Architectural Patterns

This project has been built using hexagonal architecture (aka ports & adapters), a domain-centric architectural pattern that use dependency inversion as main principle behind. It also uses tactical DDD patterns in the domain layer.

Package structure

• Application: Application Services (the use cases)
• Domain: Domain model and ports.
• Infrastructure: Adapters, configuration and infrastructure code.

Architectural shortcuts

Even though the project follows hexagonal architecture, it also takes some shortcuts, breaking consciously some architectural constraints:

• Skipping incoming ports: Incoming adapters are accessing application services directly.

Messaging patterns

In order to avoid dual writes the project uses a couple of patterns:

• transactional-outbox
• polling-publisher

Events

Domain events

A Domain-event is something that happened in the domain that is important to the business.

This service advocates for asynchronous communication instead of exposing endpoints to be consumed by clients. To do so , since the service uses also domain-driven design tactical patterns, all use-cases are producing domain-events:

• Team Created
• Team Member Joined
• Team Member Left

Integration events

An integration event is a committed event that ocurred in the past within a bounded context which may be interesting to other domains, applications or third party services, so it is the sibling of a domain event but for the external world.

Why not to publish our domain events directly? We can not publish our domain events directly for several reasons:

• Back-ward compatibility: We should provide a way to maintain backward compatibility, if we were publishing our domain events we would couple them to the external contracts.
• Different schema for messages: In almost all the companies using event-driven these messages are defined in a different schema such as avro, protobuf or json schema.
• We don't want to publish all domain-events: Sometimes we don't want to publish to our consumers all our internal domain events.

Here the contracts

Error handling

• recoverable: Domain (Eithers)
• Not recoverable: Let it crash (Exceptions, capture and deal with them at the boundary of the app)

boundary errors (shit happens) kafka retries

where are the metrics! boundary monitoring

Diagram testing

testing strategy

diagram usecases etc ...

Flyway

What about reading entrypoint???????? events, compacted topic!!!

tech-stack

spring boot undertow (nio) kafka postgresql kotlin arrow BBDD: postgresql, flyway, jdbctemplate

DDD patterns

aggregate

-tactical ddd

• ddd related patterns
• domain events domaineventpublisher outbox, simple implementation explain and links (copy from Tn or check history). dual writes (logs, metrics is ok), kafka no: https://github.com/n26/spring-transactional-outbox

eventual consistency

eda:

• dual writes
• DLQ
• tombstones
• Error handling Kafka : backoff, retries and error handling (revover)
• Replication, fallback when lag more than 5 min ?
• dual writes