Building Blocks of Domain Driven Design Part 2 - Entities and Value Objects

Associations between the model elements

As we had seen earlier there are three core model elements, Entity,Value Objects and Services. The association between the model elements should be constrained and the following are the three ways to make the associations more tractable:

1. Imposing a traversal direction.
2. Adding a qualifier,effectively reducing multiplicity.
3. Eliminating nonessential associations.

As an example, India as had many presidents as have many other countries.This is a bidrectional one-to-many relationship. Yet we seldom would start out with “Dr. A.P.J Abdul Kalam” and ask “Of which country was he the President?.

Prgamatically, we can reduce the relationship to a unidirectional association, traversable from Country to president:

Very often a deeper understanding leads to a qualified relationship and we can say that a country has only one president at a time. This qualifier reduces the multiplicity to one:

Entities

An object primarily defined by it’s identity is called an Entity.Enitites have life cycles that can radically change their form and content,but a thread of continuity must be maintained.Their identity must be defined so that they can be tracked effectively.Their class definitions,repsonsibilities,attributes and associations should revolve around their identity rather than the particular attribute they carry.

When an object is distinguished by it’s identity,rather than it’s attribute,make this primary to its definition in the model.Keep the class definition simple and focused on life cycle continuity and identity.

Identity is not intrinsic to a thing in the world;it is a meaning superimposed because it is useful.

Modelling Entities

1. Strip the Entity’s object definition down to the most intrinsic characteristics, particularly thos that identify it.
2. Add only behaviour that is essential to the concept and attributes that are required by that behaviour.
3. Beyond that, look to remove behaviour and attributes to other objects associated with the core Entity, these can be either other Entities or Value objects,
4. Each Entity must have an operational way of establishing its identity with another object even if the other object has the same attributes.
5. An identifying attribute must guranteed to be unique within the system.
6. Sometimes an identity can be created by combining certain data attributes that can gurantee the uniqueness of the identity. This approach can provide a unique key for the Entity.
7. When it is not possible to generate a unique key from a combination of attributes than the common solution is to generate a unique indentifier that can be guranteed to be unique across the system and once generated it must never change.

Value Objects

An object that represents a descriptive aspect of the domain with no conceptual identity is called a Value Object. Value objects are instantiated to represent elements of the design that we care about only for what they are,not who or which they are.

Characteristics of Value Objects

1. A Value Object can be an assemblage of other objects. For example in software for designing house plans,an object could be created for each window style.This window style could be incorporated into a window object along with height,width as well as rules governing how these attributes can be changed and combined.These windows are intricate Value objects made up of other Value objects.

2. Value objects can even reference Entities.

3. Value objects are often passed as parameters in messages between objects.

4. They are frequently transient,created for an operation and than discarded.

5. The attributes that make up a value object should form a conceptual whole.

Designing Value Objects

Since it does not matter what instance of value objects we have,this freedom can be used to make choices about copying,sharing and immutability.

1. Inorder for an object to be shared safely, it must be immutable: it cannot be changed except by full replacement.

2. The same consideration about object immutability can be made when an object passes one of its attribute to another object as a parameter or return value. This can cause any side effect, the problem can solved by making the passed object immutable or passing a copy.

3. The economy of copying versus sharing depends on the implementation environment.Although copies may clog the system with huge numbers of objects,sharing can slow down a distributed system.Sharing is best restricted to thos cases where: i. When saving space or object count in the database is critical. ii. When communication overhead is low. iii. When the shared object is strictyl immutable.

4. Try to completely eliminate bidirectional associations between value objects.If in the end such associations seem necessary in your model,rethink the decision to declare the object a Value object in the first place. Maybe it has an identity that hasn’s been explicitly recognized yet.