Big Blue Series — 13 — From Values to Value Objects

Photo by Adam Bignell on Unsplash

We sometimes get into a conversation about something that seems simple, only to find out that it has far more depth that matters than we initially thought. Rabbit trails turn into non-trivial matters.

Values in software can end up the same. A singular value is not enough because now that single value now has values and actions of its own. We need something more in line with the real world. In Blue (Evans, 2014) we turn to the middle section of chapter five to understand how to model some of this in our Domain.

The power of modern software has partially to do with the ability to assign values to properties of things. Sometimes these values standalone. Sometimes they are values of other values. And some do not have a reason to be values outside of the relationship with an Entity with which it belongs. More on this in a minute

Let’s start with a simple example and build on this idea.

In the old days of programming, we would just add more values to the main thing and name it with a prefix to show that it belongs to another value in the list of values. Here is a pseudo code example:

Order
- orderId int
- orderMailingAddressLineOne char
- orderMailingAddressLineTwo char
- orderMailingAddressCity char
- orderMailingAddressState char
- orderMailingAddressPostalCode char

So, there comes a time in the maturing growth of that thing where the single value is not enough to get the job done. To help, we create another thing, a Value Object. Here is a pseudo code example:

Order
- orderId int
- MailingAddress MailingAddress
MailingAddress
- lineOne char
- lineTwo char
- city char
- state char
- postalCode char

The naming is not as important in this example as the relationship so if you have other names you would have used, that is great. The key here is that this object relationship is important as a function of the model and in the code. Fortunately, this type of relationship is common practice today in most programming languages. And there are thousands of examples I could make here but let’s quickly move to the other key points for today.

Values In The Wild

Value Objects have no critical Identity to track like a Customer or an Order. They just don’t rise to the level of needing to care for the protection and management of that Identity. And many times these Value Objects are attached to nothing at all. They serve a purpose and are gone.

These happen so often in software we don’t think much about them. They are created, used, and disposed of with no need to care about updating a database to track that Value Object at all.

I think of an old steam engine. The coal goes into the fire to make the steam, is burned up and gone. The coal needs no identity. The steam needs no identity. The power it produces needs no identity. It all is created, used, and gone.

Values of Other Things

I want to further clarify that if a Value Object is part of another Value Object or an Entity, then that relationship matters and should be honored even if the Value Object itself has no identity of its own. There is a lot to this aspect of these relationships, but for now, just know that we want to protect the value in the relationship in the same fashion that we protect Entity identity.

Value Objects with Entities On Board

Sometimes you need some random object to know about other details of the model that are modeled as Entities. Values like a Schedule may not need Identity, but if that Schedule references a Client, then you can see how a Value Object knowing about an Entity would have common use in Domain modeling.

There is more to how we manage Entities and Value Objects in our model to protect their identities and/or relationships if necessary and we will look at more of this as we get closer to Aggregates. To get us closer to that we will need to talk about functionality.

In the next installment we will go through the underlying principles of crafting actionability in the model. Dare I say this is one of the most underutilized concepts in software development today. I might change my mind but after years of doing this, I think most developers get lured into the objects physical properties and make the actions something that is added on elsewhere. More on this next time.

Until then…

I hope I see you in the next installment of — the Big Blue Series.

Photo by Kelly Sikkema on Unsplash

References

Evans, E. (2004). Domain-Driven Design: Tackling Complexity in the heart of software. Addison-Wesley Professional