Domain-driven design (DDD) concepts like bounded contexts and messaging can be used to build reliable systems that can scale with the business changes. Indu Alagarsamy recently spoke at the QCon New York 2019 Conference about using the combination of well-defined bounded contexts and events to develop autonomous microservices that are flexible to adapt to the business changes.
Alagarsamy said when you start to use the technology of messaging to communicate between clean and well-defined bounded contexts, you can remove temporal coupling. Bounded contexts provide clarity, and the models in each bounded context are logically consistent and can evolve freely.
She discussed an example use case of an e-commerce application where the "product" is one of the core entities. The product entity is context-based, and means different things to different domain teams as follows:
- Sales: It's a thing that has a description, images, and a price
- Inventory: It's a thing that is either available or not
- Shipping: It's a thing that has weight and dimensions that needs to be packaged
Creating unified models are hard, and finding the right boundaries between the business domain can be a challenge. She suggested that domain models can be split according to teams and departments to help with a better organization of the model. It can also be split according to business processes in the system.
Alagarsamy discussed how bounded contexts communicate with each other, using the example of an Airline application.
She talked about two important components of event driven microservices: Commands and Events. Events are useful as the communication mechanism between different bounded contexts. They help minimize the temporal coupling between bounded contexts. Commands are useful as a communication style within the single bounded context. Writing code becomes much simpler once you model the events and commands.
During the requirements gathering phase, look for key word "when" in the description of business requirements; this usually indicates a business event. She discussed some examples of Events in an airlines application.
WHEN an aircraft type is changed:
- Passenger gets notified with a new booking proposal
- Passenger can cancel flight
- Passenger can accept the proposed booking
She also talked about how events and messages are associated with business processes in an application. A business process can be triggered by an event from a different bounded context. Multiple messages can take part in a business process. When designing the messages, make them immutable, i.e. get rid of public setters. Instead, set the properties at construction time of the domain class.
The saga pattern can be used to manage multiple messages that take part in the same transaction. The pattern allows you to take compensating actions in case any of the steps in the business process don't succeed.
Event storming is another critical step in the overall requirements analysis effort. It's a collaborating technique used by development teams with business stakeholders for the exploration of complex business domains. Domain modeling using event storming techniques helps to identify when an event occurs, and what actions the application should take. We can use this to align the commands with the events.
It's also important to use proper naming conventions for the various elements in the domain model. Give your command handlers proper names and verify the names during code reviews and peer reviews. Check for language and naming of events, classes, and handlers.
Alagarsamy concluded the presentation by saying that models are not perfect, and that teams should follow the practices to ensure their domain models are in good alignment with business objectives and requirements.
- Talk to domain experts. Event storm with them.
- Evolve and refactor with an obsession for domain language.
- Strive for Autonomy. Use events to communicate between bounded contexts.
If you are interested in Domain Driven Design topics, check out the original book by Eric Evans or the recent book titled Domain-Driven Design: The First 15 Years which includes essays from the DDD community leaders, including Indu Alagarsamy, and the Service Modeling workshop.