Beyond Technologies: Domain Driven Design - ENTITIES, VALUE OBJECTS, DOMAIN SERVICES AND AGGREGATES

Introduction

In this post I sum up concepts about Domain Driven Design:

§          Entities

§          Value Objects

§          Domain Services

§          Aggregates

I recommend you when you read this post not to think in technologies. Put away the technical knowledge and think from an upper level, from an architectural level.

ENTITY

An object defined primarily by its identity and not by their attributes. ENTITIES have life cycles that can change their form and content, but a thread of continuity must be maintained. Their class definitions, responsibilities, attributes, and associations should resolve around who they are, rather than the particular attributes they carry.

VALUE OBJECT

An object that represents a descriptive aspect of the domain with no conceptual identity and we care about only for what they are, not who or which they are.

VALUE OBJECTS are often passed as parameters in messages between objects. They are frequently transient, created for an operation and then discarded.

VALUE OBJECTS are used as attributes of ENTITTIES (and other VALUES).

DOMAIN SERVICES

There are important domain operations that can not find a natural home in an ENTITY or VALUE OBJECT. Some of these are intrinsically activities or actions, not things. Forcing the required domain functionality to be responsibility of ENTITY or VALUE either distorts the definition of a model-based object or adds meaningless artificial objects.

The name service emphasizes the relationship with other objects. Unlike ENTITIES and VALUE OBJECTS, it is defined purely in terms of what it can do for a client. A SERVICE tends to be named for an activity. A SERVICE should still have defined responsibility, and that responsibility and the interface fulfilling it should be defined as part of the domain model. Operations should come from the UBIQUITOUS LANGUAGE or be introduced into it. Parameters and results should be domain objects.

A DOMAIN SERVICE has three characteristics:

1.     1. The operation relates to a domain concept that is not a natural part of an ENTITY or VALUE OBJECT.

2.     2. The interface is defined in terms of other elements of the domain model.

3.     3. The operation is stateless.

SERVICES IN LAYERS

Application services: are the interface used by the outside world. These services could map outside messages to internal operations and processes, communicating with services in the Domain and Infrastructure layers to provide cohesive operations for outside clients.

Domain services: Embeds business rules. These use the infrastructure services to do their tasks.

Infrastructure services: communication with external resources like databases, file systems, web service end points, etc.

AGGREGATES

An AGGREGATE is a set of associated objects that we treat as a unit for the purpose of data changes. Each AGGREGATE has a root and a boundary.

§          The boundary defines what is inside the AGGREATE.

§          The root is a single, specific ENTITY contained in the AGGREATE. The root is the only member that outside objects are allowed to hold references to, although objects within the boundary may hold references to each other.

It is difficult to guarantee the consistency of changes to objects in a model with complex associations. Invariants are consistency rules that must be maintained whenever data changes and will involve relationships between members of the AGGREGATE. The invariants applied within an AGGREAGATE will be enforced with the completion of each transaction.

Rules for implementing AGGREGATES:

1. The root ENTITY has global identity and is ultimately responsible for checking invariants. ENTITIES other than root inside the boundary have local identity, unique only within the AGGREGATE, because no outside object can ever see it out of the context of the root ENTITY.

2.     2. Nothing outside the AGGREGATE boundary can hold a reference to anything inside, except to the root ENTITY.

3.     3. The root ENTITY can hand references to internal ENTITIES to other objects, but those objects can use them only transiently, and they may not hold on to the reference. The root may hand a copy of a VALUE OBJECT to another object, and it does not matter what happens to it, because it is a VALUE and no longer will have any association with the AGGREGATE.

4.     4. Only AGGREGATE roots can be obtained directly with database queries. All other objects must be found by traversal of associations.

5.     5. Objects within the AGGREGATE can hold references to other AGGREGATE roots.

6.     6. A delete operation must remove everything within the AGGREGATE boundary at once.

7.     7. When a change to any object within the AGGREGATE boundary is committed, all invariants of the whole AGGREGATE must be satisfied.  

Example - Bank Customer

References

Eric Evans 2004. Domain Driven Design. Tackling Complexity in the Heart of Software. Addison-Wesley.