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.
Implementing event-based communication between microservices (integration events)
As described earlier, when you use event-based communication, a microservice publishes an event when something notable happens, such as when it updates a business entity. Other microservices subscribe to those events. When a microservice receives an event, it can update its own business entities, which might lead to more events being published. This is the essence of the eventual consistency concept. This publish/subscribe system is usually performed by using an implementation of an event bus. The event bus can be designed as an interface with the API needed to subscribe and unsubscribe to events and to publish events. It can also have one or more implementations based on any inter-process or messaging communication, such as a messaging queue or a service bus that supports asynchronous communication and a publish/subscribe model.
You can use events to implement business transactions that span multiple services, which gives you eventual consistency between those services. An eventually consistent transaction consists of a series of distributed actions. At each action, the microservice updates a business entity and publishes an event that triggers the next action. Figure 6-18 below, shows a PriceUpdated event published through and event bus, so the price update is propagated to the Basket and other microservices.
