Domain-Driven Design: Tackling Complexity in the Heart of Software

Modeling E
NTITIES
It is natural to think about the attributes when modeling an object, and it is quite important to
think about its behavior. But the most basic responsibility of 
ENTITIES
is to establish continuity so
that behavior can be clear and predictable. They do this best if they are kept spare. Rather than
focusing on the attributes or even the behavior, strip the 
ENTITY
object's definition down to the

---

most intrinsic characteristics, particularly those that identify it or are commonly used to find or
match it. Add only behavior that is essential to the concept and attributes that are required by that
behavior. Beyond that, look to remove behavior and attributes into other objects associated with
the core 
ENTITY
. Some of these will be other 
ENTITIES
. Some will be 
VALUE OBJECTS
, which is the
next pattern in this chapter. Beyond identity issues, 
ENTITIES
tend to fulfill their responsibilities by
coordinating the operations of objects they own.
The customerID is the one and only identifier of the 
Customer_ENTITY_in_Figure_5.5,_but_the_phone_number_and_address_would_often_be_used_to_find_or_match_a_Customer'>Customer
ENTITY
in Figure 5.5, but the phone
number and address would often be used to find or match a 
Customer
. The name does not 
define
a person's identity, but it is often used as part of the means of determining it. In this example, the
phone and address attributes moved into 
Customer
, but on a real project, that choice would
depend on how the domain's customers are typically matched or distinguished. For example, if a
Customer
has many contact phone numbers for different purposes, then the phone number is not
associated with identity and should stay with the 
Sales Contact
.
Figure 5.5. Attributes associated with identity stay with the