DDD - Modelling the Domain - Aggregates

The concept of Aggregate was introduced by Evans (2003) as a reference term to a “cluster of associated objects that we treat as a unit for the purpose of data changes”. In other words, an Aggregate defines a set of Entities and Value Objects that are collaborating as an atomic unit whose state is always valid (Evans, 2003). Among all DDD building blocks, the Aggregates is the most misunderstood (Vernon, 2013).

Every aggregate has a virtual boundary defining which objects are inside and a root object which is typically an Entity (Evans, 2003). The aggregate root acts as a gatekeeper, controlling access to the internals and is the only object that can be referenced by other domain objects (Evans, 2003). Furthermore, objects inside an aggregate may reference each other as well other aggregates (Evans, 2003). Aggregates are distinguished by the identity of the root object, however the identity of other contained entities is local to the aggregate (Evans, 2003).

Aggregates are not an alternative way to define object graphs and are meant to enforce invariants and form a consistency boundary (Evans, 2003; Vernon, 2013). Invariants are business rules or constraints that an aggregate must comply to. Whenever the state of an aggregate is modified all rules must be enforced (Evans, 2003). As a result, an aggregate remains always in a consistent state.

In the figure below, the context is modelling a project management system and the parts of the Project aggregate and the typical design rules are visualized. The aggregate boundary contains the Project entity, the Task entity and the Assignment value object, all three acting as a unit. Conceptually a Task and an Assignment do not exist on their own and their life cycle is part of a project's initiation. The root of the aggregate is the Project which has a global identity and a Customer entity may hold references to a list of projects. Tasks are created and removed only using the public interface of the Project, which enforces any related invariants. In this case, every Project has a maximum number of tasks and a maximum number of tasks per employee. In addition, retrieving tasks, returns tuples of immutable data structures and not the actual Task instances isolated inside a Project. The Assignment is a value object created by the Project when a task is assigned to an Employee. Although, the Assignment holds a reference to an Employee, the opposite is not permitted.

As shown above, there are many rules to follow in successfully designing aggregates. In most object-oriented programming languages there is no concept of a cluster of objects acting as a unit. Thus, a team of developers need to agree on the details and show discipline when coding aggregates (Evans, 2003).

References

• Evans, E. (2003) Domain-Driven Design: Tacking Complexity In the Heart of Software. Boston: Addison-Wesley.
• Vernon, V. (2013) Implementing Domain-Driven Design. Boston: Addison-Wesley.

This post is an excerpt of my MSc Thesis titled "Applying Domain-Driven Design in Python - designing a self-hosted Read-it-Later service" (January 2014).