3 Useful Concepts in Domain Driven Design
We look at 3 useful types of objects in domain driven design, what they do, and how they differ. Entities, Value Objects and Services.
This is part three of a summary series I am doing on a podcast I co-host, you can find it at: www.iterationpodcast.com
Part one: What is Domain Driven Design? — Part two: Using Domain Driven Design
Entities
“Many objects are not fundamentally defined by their attributes, but rather by a thread of continuity and identity.” — Evans in Domain Driven Design
We can think about identity to begin understanding entities in domain driven design. Identity does not mean name. When we ask the question “what defines a person?”, the answer is not their name, or their social security number, or their appearance. The first two can be changed in an instant, and the last changes all the time anyways.
In the context of software, entities are defined by unique characteristics. If we care about the instance of an object, it is an entity.
For example, consider an app that predicts what your boss is going to wear, depending on the data we collect. By tracking what the boss wears everyday, the app gets smarter. The model for this app would catalogue the outfits of the boss. In the database, we could have 3 tables: shirt, pant, and outfit. The shirts and the pants would have attributes like color or brand.
Lets say on December 28th, the outfit is grey polo and olive denim jeans. The instance of this specific outfit on this specific day is an entity object. The instances of olive denim jeans does not matter, but the collection of the outfit on that date does. The outfit on a specific date is a unique instance, an entity.
What kind of objects are olive denim jeans or grey polos then?
Value Objects
Value objects are defined by their attributes. They are not unique. A simple example is to think of a child coloring a picture. The child has a big box of crayons with multiple crayons of each color. When using a blue crayon, the child does not care about the specific blue crayon. She only cares about the fact that it is blue.
In the example of the boss outfit app, olive denim jeans and grey polos are value objects. The specific instance of these objects do not matter, but their attributes do.
Services
In Domain Driven Design, Evans says that “some concepts from the domain aren’t natural to model as objects…a service tends to be named for an activity, rather than an entity — a verb rather than a noun.”
We naturally think of objects as nouns. Think of a keyboard, computer, mouse etc. A service, though, is an action, a verb. Service objects, like an ice maker or an air conditioner, are both verbs and nouns. We know what they are and what they do.
In this chapter, Evans states that a good service has three characteristics. First is that the operation relates to a domain concept that is not a part of an entity or value object. In other words, it does things that do not relate to a specific object. For example, sending a welcome message is not related to the user object.
The second characteristics is that the interface is defined in terms of other elements of the domain model. A good service has a noun from the domain model. For example, when we think of a lesson service, there is a lesson object and the service is managing that object. This way, we are not muddying up our different objects.
The last characteristics is that the operation is stateless. We want the service to only accept a set of data or an object and spit out a different state of the object. The service does not hold data itself, or store data to the database. It only absorbs data, takes whatever action it needs to, and then spits out an object again.
Iteration — A weekly podcast about development and design through the lens of amazing books, chapter-by-chapter. We do our best to be code-agnostic but we talk a lot about Rails, JavaScript, React, React Native, design, business and startups. — Check it out
P.S. This article was written with help from Senem Soy based on content from our podcast episode. Thanks Senem!
