In traditional object-oriented design, a domain model is a collection of classes and relationships between classes. The classes are usually organized into packages. But interestingly, the explicit boundaries of each business object are missing from this kind of traditional domain model. This lack of boundaries can sometimes cause problems, especially in microservice architecture.

An aggregate is a cluster of domain objects within a boundary that can be treated as a unit. It consists of a root entity and possibly one or more other entities and value objects. Many business objects are modeled as aggregates. Aggregates decompose a domain model into chunks, which are individually easier to understand. They also clarify the scope of operations such as load, update, and delete. These operations act on the entire aggregate rather than on parts of it. An aggregate is often loaded in its entirety from the database, thereby avoiding any complications of lazy loading. Deleting an aggregate removes all of its objects from a database. Aggregates must obey is that a transaction can only create or update a single aggregate.

In the context of DDD, a domain event is something that has happened to an aggregate. A domain event is a class with a name formed using a past-participle verb. Usually it contains domain object Id also has metadata, such as the event ID, and a timestamp. It might also have the identity of the user who made the change, because that’s useful for auditing. Approach known as event enrichment is for events to contain information that consumers need. It simplifies event consumers because they no longer need to request that data from the service that published the event. Although event enrichment simplifies consumers, the drawback is that it risks making the event classes less stable. An event class potentially needs to change whenever the requirements of its consumers change. This can reduce maintainability because this kind of change can impact multiple parts of the application. Satisfying every consumer can also be a futile effort. Fortunately, in many situations it’s fairly obvious which properties to include in an event.

Event storming is an event-centric workshop format for understanding a complex domain. It involves gathering domain experts in a room, lots of sticky notes, and a very large surface – a whiteboard or paper roll – to stick the notes on. The result of event storming is an event-centric domain model consisting of aggregates and events.

Connect with me on LinkedIn