Big Blue Series —12 — Identifiably Unique Entities
In Domain-Driven Design (Evans, 2004), the book I am calling “Blue” in this series, we have some building blocks to work with in the software modeling world starting in Chapter Five. Once we know our Domain, decided on starting Bounded Contexts, and desire to develop a Ubiquitous Language, we begin to model. Modeling can be done many ways. Many consultants have their own paradigm, and some borrow from luminaries and inventors of our day. All of them are seeking the same end, to identify what the Entities are, what Value Objects they care about and what Events matter to them and how to interconnect all of it. There are also Domain Services, a topic that will is interesting to cover because “Services” as a term is quite often used in several contexts, something we will discuss later.
Modeling out a Domain is fundamentally asking questions like, “What do these things do? Why and when?” This is what we are trying to figure out. Eventstorming, some proprietary Domain Modeling concepts, Service Blueprints, Example Mapping and more are all aimed at unearthing the essentials of the Domain — just slightly different and with more passion from some than others.
Entities are critical model elements that make up key concepts within the DNA of the Domain. Entities basically have a fingerprint. Think of Customer or an Order. When your software is managing any of their needs, it needs to be with the Customer or Order that matters in context. We cannot just change the credit card on file on any customer, it must be the correct customer. There may be many records of a Customer, Order or Product, but each one is unique and must be managed as though they have a fingerprint in the system. They must have identification and that normally means some sort of an ID as a property of that Entity. IDs are generally exclusive to this concept of an Entity. Value Object won’t need this, and it is a good idea not to have things we don’t need. More on Value Objects in a follow up article.
Developing software in the old days we had rules about data tables. All of them must have an ID field that is auto-populated so that we had a hook to be able to get back to a specific record if we needed to. That concept just bled over into our code up several levels. We did not think much of it. Turns out, not everything needs a fingerprint.
Some Entities are not obvious by their name. The key question to ask when wondering if something is an Entity or not is, “Do the actions I am going to take with this thing have to happen on a specific one, or can we just use any version of this thing?”
I normally use a color as an example. Red for instance. Once you define red in technical terms, it generally does not matter if I use one instance of that color Red or another. If I have the Red I am looking for, all is well.
But that is too easy. Let’s look at the same Thing in two contexts, something Evans develops into a clear picture of an Entity in Blue. He uses the concept of an Address. In many contexts, an Address is a property of a customer or Vendor entity, but, in and of itself, it does not need an ID. That makes sense unless you are the Postal Service, where they need to track all addresses uniquely. It truly depends on the context.
Let’s look at another idea that might crop up in the same domain. Preference options. In one way, a user’s choice of preferences in the system are just properties of that user. But if you are in the backend Maintenance system of the company managing a more robust list of preferences, that then calls for some identification.
Entities have fingerprints, and entities can be discovered in surprising places when you apply that question of the need for identity. If we only want to manipulate a thing and target one copy over all the rest, that is a good candidate for an Entity.
Next, we will look at Value Objects in comparison to Entities.
Until then…
I hope I see you in the next installment of — the Big Blue Series.
References
Evans, E. (2004). Domain-Driven Design: Tackling Complexity in the heart of software. Addison-Wesley Professional
