How Can Statistics Enhance the Building Blocks of Domain-Driven Design? (Part-1)
It has been two decades since Eric Evans introduced the Domain-Driven Design approach in 2003. His approach led to many discussions about the method of analysis and design of complex domains during these years, also many ideas emerged and some of them have been widely accepted.
Evans introduces the DDD approach as a decision framework which is suitable for making decisions about a wide range of design aspects, from strategical design to tactical design.
So, his proposed framework consists of glorious ideas and a set of building blocks for developing a rich domain model. The Value Object is one of the DDD’s technical design patterns, and since its introduction, many advocates have been discussing about its usage and its implementation details in different programming languages, in addition to its technical concerns.
But looking at all these published contents, you will find that the common theme of most of them (if not all of them) is the following four topics:
1- Immutability of Value Objects.
2- Checking equality of two Value Object.
3- Value Object’s life-time compared to Entity and how they are usually persists.
4- How to distinguish the value object from an entity accurately.
There is no doubt about the importance of the topics above. But by being more precise, we can identify a similarity between the first three cases, which is their technical aspect overcoming their analytical aspect.
This is a notable sign indicating that the intellectual effort of the advocates is more related to the implementation details rather than analysis problems. Whereas the lack of new and applicable ideas for modeling complex domains, cannot be compensated by any programming language.
The fourth item stands out as particularly valuable for analysis and design tasks compared to the preceding three. It serves as a general guideline applicable across frameworks and languages. However, discussions on Value Objects often revolve around a fundamental question: Value Object or Entity? The answer depends on the problem context, emphasizing the need to carefully consider how to model a concept. While this awareness is crucial, it typically remains a broad cautionary note, sometimes leaving readers with more questions than answers and lacking practical guidance for analysts and domain modelers.
While I’ve briefly touched upon the Value-Object-centric discourse within the software development community, the goal of this article isn’t to reiterate those discussions. Instead, it aims to introduce fresh perspectives on Value Objects, elevating their role beyond conventional boundaries to enhance their impact on analysis and design.
I intend to present ideas that can empower developers to create models that are more robust, expressive, and aligned with the problem domain.
Let’s begin!
Let’s delve into the term “Value Object” and its components. Focus your attention on the term “Value.”
Question: What does Value signify and how does it benefit us?
Value: Let’s take the number 3 as an example. In isolation, this singular “value” doesn’t convey details about the context in which it exists. However, values derive significance and utility through contextualization. For instance, the number 3 gains specificity and relevance when associated with attributes like length, time, temperature, and so on. For example: 3 meters long, 3 years old, 3 degrees Celsius, 3 kg.
Values can exhibit intricate structures beyond mere numerical representations. Examples include a fingerprint, coordinates of a polygon in two-dimensional space, a numerical matrix, or the contents of an XML file. Variables play a crucial role in representing values in a comprehensible manner. (1)
Variable: A “variable” acts as a container for a “value.” Consider variables such as length, temperature, age, and weight, each capable of holding a value. Furthermore, different variables can share the same value, like 3 meters long and 3 years old.
Through variables and values, we can accurately describe and record our observations of various events. Blood type, gender, mother tongue, pregnancy status, date of birth, city of residence, cancer progression stage, blood hemoglobin levels, medication dosages, competition scores, clothing sizes, colors, races, volumes, temperatures, and more represent everyday variables we encounter.
Each variable adheres to specific rules when accepting values. For instance, the color variable may be defined in RGB format, while the weight variable cannot be negative.
Having grasped the concept of variables and their connection to values from a statistical perspective, the central question arises: Can we categorize these variables in a manner that not only facilitates analysis, design, and domain modeling but also remains independent of any specific domain context?
Exploring this query led me to insights from the field of statistics. In the subsequent section, I will delve deeper into statistical classifications of variables and explore how they can enrich the foundational elements of Domain-Driven Design (DDD).
