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

Entities (a.k.a. Reference Objects)
Many objects are not fundamentally defined by their attributes, but rather by a thread of
continuity and identity.
A landlady sued me, claiming major damages to her property. The papers I was served described
an apartment with holes in the walls, stains on the carpet, and a noxious liquid in the sink that
gave off caustic fumes that had made the kitchen wallpaper peel. The court documents named me
as the tenant responsible for the damages, identifying me by name and by my then-current
address. This was confusing to me, because I had never even visited that ruined place.
After a moment, I realized that it must be a case of mistaken identity. I called the plaintiff and told
her this, but she didn't believe me. The former tenant had been eluding her for months. How could
I prove that I was not the same person who had cost her so much money? I was the only Eric
Evans in the phone book.
Well, the phone book turned out to be my salvation. Because I had been living in the same
apartment for two years, I asked her if she still had the previous year's book. After she found it
and verified that my listing was the same (right next to my namesake's listing), she realized that I
was not the person she wanted to sue, apologized, and promised to drop the case.
Computers are not that resourceful. A case of mistaken identity in a software system leads to data
corruption and program errors.
There are special technical challenges here, which I'll discuss in a bit, but first let's look at the
fundamental issue: Many things are defined by their identity, and not by any attribute. In our
typical conception, a person (to continue with the nontechnical example) has an identity that
stretches from birth to death and even beyond. That person's physical attributes transform and
ultimately disappear. The name may change. Financial relationships come and go. There is not a
single attribute of a person that cannot change; yet the identity persists. Am I the same person I
was at age five? This kind of metaphysical question is important in the search for effective domain
models. Slightly rephrased: Does the user of the application 
care
if I am the same person I was at
age five?

---

In a software system for tracking accounts due, that modest "customer" object may have a more
colorful side. It accumulates status by prompt payment or is turned over to a bill-collection agency
for failure to pay. It may lead a double life in another system altogether when the sales force
extracts customer data into its contact management software. In any case, it is unceremoniously
squashed flat to be stored in a database table. When new business stops flowing from that source,
the customer object will be retired to an archive, a shadow of its former self.
Each of these forms of the customer is a different implementation based on a different
programming language and technology. But when a phone call comes in with an order, it is
important to know: Is this the customer who has the delinquent account? Is this the customer that
Jack (a particular sales representative) has been working with for weeks? Is this a completely new
customer?
A conceptual identity has to be matched between multiple implementations of the objects, its
stored forms, and real-world actors such as the phone caller. Attributes may not match. A sales
representative may have entered an address update into the contact software, which is just being
propagated to accounts due. Two customer contacts may have the same name. In distributed
software, multiple users could be entering data from different sources, causing update transactions
to propagate through the system to be reconciled in different databases asynchronously.
Object modeling tends to lead us to focus on the attributes of an object, but the fundamental
concept of an 
ENTITY
is an abstract continuity threading through a life cycle and even passing
through multiple forms.