Summary

In applications using a domain driven design (DDD) approach events and commands should be communicated using a decoupled mechanism. In most cases this is achieved by using a message broker. If a business transaction relates to different bounded contexts/domains it can span different "domain services" each having their own data persistence. As a consequence communication needs to be transactional as well. Transactional communication can be achieved by several design patterns (each having own benefits and drawbacks).

Design patterns:

• Distributed transaction patterns for microservices compared:
  • modular monolith
  • two-phase commit
  • orchestration
  • choreography (variants: Publish-then-local-commit dual write, Local-commit-then-publish dual write, without dual write, outbox pattern, event sourcing)
  • parallel pipelines
• Transactional outbox pattern
• Transaction log tailing

Exemplary transport backend alternatives:

• MassTransit transports: RabbitMQ / Azure Service Bus / Amazon SQS / ActiveMQ / gRPC / in memory / Kafka / SQL

Example implementations:

• MassTransit (Commands / Events) (C#) / Saga pattern support
• NServiceBus (C#)
• Eventuate Tram (Java) / Saga Pattern support

Basic Example

No response

Drawbacks and Impact

No response

Unresolved questions

No response