Tackle Business Complexity in a Microservice with DDD and CQRS Patterns

Posted 2020-12-09 chucklu

Domain events: design and implementation

 

Domain events versus integration events

Semantically, domain and integration events are the same thing: notifications about something that just happened. However, their implementation must be different. Domain events are just messages pushed to a domain event dispatcher, which could be implemented as an in-memory mediator based on an IoC container or any other method.

On the other hand, the purpose of integration events is to propagate传播 committed transactions and updates to additional subsystems, whether they are other microservices, Bounded Contexts or even external applications. Hence, they should occur only if the entity is successfully persisted, otherwise it‘s as if the entire operation never happened.

As mentioned before, integration events must be based on asynchronous communication between multiple microservices (other Bounded Contexts) or even external systems/applications.

Thus, the event bus interface needs some infrastructure that allows inter-process and distributed communication between potentially remote services. It can be based on a commercial service bus, queues, a shared database used as a mailbox, or any other distributed and ideally push based messaging system.

 

Domain Events vs. Integration Events in Domain-Driven Design and microservices architectures

Summary

Therefore, the global approach I like to do is the following:

Domain Events: you add or raise domain events from the domain entity classes (with or without using the “two phase” approach from Jimmy, which is better) only for intra-domain communication, when the domain events scope is purely within the domain itself, like within a single microservice’s domain.

Integration Events: You publish integration events using an EventBus.Publish() from outside of the domain entity classes (from the infrastructure or even the application layer like the Command-Handlers) when you need to propagate state changes across multiple microservice or out-of-process systems.

Conclusion

Basically, by differentiating between Domain Events and Integration Events you can solve the issue of dealing with transactions

since domain events are always scoped within a transaction

but integration events (using an EventBus.Publish()) are only published to the outside world if the transaction was committed successfully.

By doing this you can be sure that other domain-models, microservices and external systems do not react on something that in fact has rolled back and does not exist anymore. You make sure about consistency across out-of-proc systems, like microservices.

 

https://martinfowler.com/eaaDev/DomainEvent.html

 

Implement value objects