To design a domain model, DDD identifies basic patterns:
- • Entity is an object with an individual identity. In an e-commerce application, the customer or the items could be examples for Entities. Entities are typically stored in databases. However, this is only the technical implementation of the concept Entity. An Entity belongs in essence to the domain modeling like the other DDD concepts.
- • Value Objects do not have their own identity. An address can be an example of a Value Object, for it makes only sense in the context of a specific customer and therefore does not have an independent identity.
- • Aggregates are composite domain objects. They facilitate the handling of invariants and other conditions. An order, for instance, can be an Aggregate of order lines. This can be used to ensure that an order from a new customer does not exceed a certain value. This is a condition that has to be fulfilled by calculating values from the order lines so that the order as Aggregate can control these conditions.
- • Services contain business logic. DDD focuses on modeling business logic as Entities, Value Objects, and Aggregates. However, logic accessing several such objects cannot be sensibly modeled using these objects. For these cases there are Services. The order process could be such a Service, for it needs access to items and customers and requires the Entity order.
- • Repositories serve to access all Entities of a type. Typically, there is a persistency technology like a database behind a Repository.
- • Factories are mostly useful to generate complex domain objects. This is especially the case when these contain for instance many associations.
Aggregates are of special importance in the context of microservices: within an Aggregate consistency can be enforced. Because consistency is necessary, parallel changes have to be coordinated in an Aggregate. Otherwise two parallel changes might endanger consistency. For instance, when two order positions are included in parallel into an order, consistency can be endangered. The order has already a value of €900 and is maximally allowed to reach €1000. If two order positions of €60 each are added in parallel, both might calculate a still acceptable total value of €960 based on the initial value of €900. Therefore, changes have to be serialized so that the final result of €1020 can be controlled. Accordingly, changes to Aggregates have to be serialized. For this reason, an Aggregate cannot be distributed across two microservices. In such a scenario consistency cannot be ensured. Consequently, Aggregates cannot be divided between microservices.