Decoupled, transactional communication of domain events and commands

[fkromer]

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

---

Note

While we are open for sponsoring on GitHub Sponsors and
OpenCollective, we also utilize Polar.sh to engage in pledge-based sponsorship.

Check out all issues funded or available for funding on our Polar.sh dashboard

• If you would like to see an issue prioritized, make a pledge towards it!
• We receive the pledge once the issue is completed & verified
• This, along with engagement in the community, helps us know which features are a priority to our users.