Domain Driven Design Building Blocks

When the Bounded Context and the Context map is clear, the building blocks can be designed.

Building Blocks exists in their Bounded Context.

A Bounded Context is the central part of DDD and marks the boundaries of a domain. Within a Bounded context, the domain objects are in a consistent state with each other.

Aggregates are groups of entities. The root entity in an aggregate is in the lead in terms of access to the object graph and lifecycle.

You should structure your microservices around the Bounded Context. You can group the entities together to form aggregates to make the microservice more coarse grained if preferred or use smaller aggregates or per microservice one entity to make the service more fine grained. So a big aggregate can be separated in smaller aggregates in some situations.

Smaller aggregates with one entity and value objects are better. They are easier to test and keep consistent.

Also do not implement direct references to other root entities. By example, in place of

ClassA {

    private ClassB classB;



ClassA {

    private long idOfClassB;



if ClassB is not part of the aggregate. On this way, the depended aggregate does not have to be updated in the same transaction.

Only one aggregate should be updated per transaction. Aggregates should be updated in separate transactions which leads to eventual consistency. So the eventual consistency should be modeled around aggregates.

You have to take account and decide which parts of your model must be updated in an atomically manner.

Entities are core business objects of a given bounded context model. They are defined by its constant identities. Their properties may change but their identity is immutable. Each entity has also his own lifecycle.

The DDD Entity is very similar to the JPA Entity. However, a JPA entity is not a DDD entity. They might be similar in simple cases, still they are conceptually different. A DDD Entity contains the Business Logic and not the persistent context as in case of JPA.

Value Objects are objects without a constant identity. They drive their identity from the combination of their values. Value objects do not have their own lifecycle, they inherit it from Entities that referencing them.

Factories are objects with only one responsibility: creating other objects. When an object creation gets complex, it might be a good idea to use factories to standardise the creation of the objects. The logic for the creation of the object can be placed in a central location and can be encapsulated. Beside the creation of an object, factories should not contain any other logic.

Repositories contains methods to retrieve domain objects.

Services keeps the business logic which does nog belong to a domain object like an entity.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s