You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
fkromer
changed the title
Decoupled communication of domain events and commands
Decoupled, transactional communication of domain events and commands
May 14, 2024
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:
Exemplary transport backend alternatives:
Example implementations:
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
The text was updated successfully, but these errors were encountered: