Primitive Value Object
Talking about Primitive value object today, is cool. We will be discussing about high level performance, scalability, relationships, etc. This article will explain some model specific attributes that seem obvious. For example, you have the Product entity; is the price a number? Or you have a Job entity; is the status just a string?
Using a primitive value (number, text) for these attributes can bring issues in the future. What if you want to sell the product in different countries and the price attribute is just a number? Or, what if you want the status of Jobs to be related to only one workflow and you have only a text?
The examples of price and status show how some attributes that seem just a primitive value encapsulate a whole concept. Price encapsulates currency, country, even some dates. Status can be part of a workflow; it encapsulates time, users, next steps. A status means more than just some text. Knowing this does not only apply to database modeling but also to our daily code.
Helpful Questions?
If two attributes have the same value, are they equal?
If two job statuses have the same value, does that mean it’s the same status?
No, status can belong to different workflows or to different users, and even though they have the same value might mean other things.
Another example is with the amount attribute. If we have two amounts of “100”, do they mean the same? No, because one can be 100 units, while the other 100gr.
Can we have more than one value in that attribute? What differentiates them?
Can a user have more than one phone number? What differentiates them? For example, one kind of differentiation is the home phone or the work phone. A phone number has more than just the number; it also has a type of phone. Therefore, the phone is not just a number.
If the value changes, does it still represent the same concept?
For example, can a tag be renamed and keep the same references? If we consider tags belonging to a user and editable, renaming a tag means changing the name of an entity. But, if we stored the tag as a text, how do we know which tag to rename, which tag belongs to which user?
These questions are not an exhaustive list. Yet, it’s a good starting point to identify and avoid future problems when modeling the data.
Most times we tend to overengineer our code, this leads to error. I am not proposing that you start using a collection of values always, with “first name” or age, for example. But, just like everything in life, you need to find a balance. Always consider the project data before modeling.
:)
