Our Beginning
When we first encounter Domain Modeling we might find ourselves surrounded by examples of people, animals or cars. These concepts are given properties and we start to combine and collect them. We quickly learn the nature of inheritance by learning about specialization of generic concepts; a dog vs. an animal, etc. Then we discuss the behavior of these concepts and have to ask does a Dog: bark, speak or just make noise? So composition is then introduced as an answer to all the noises to be made. At this point the concept of Object Oriented design is starting to take shape. We learn that in these constraints an Object, as it was presented, defines its shape and its behavior.
With that, we may then be thrust into Domain Driven Design wherein we learn about the Legos of our Domain Model; the aggregate, entity, value object and so on. Concepts well in hand we construct Rich Domain Models ensuring their invariants and described via our ubiquitous language. We stand back with pride at our carefully choreographed model as it expresses our Domain Experts understanding of the Domain Space.
The Test of Time
All is well and good until the underpinnings of our Rich Domain Model are redefined, shuffled, evolved and put through the meat grinder that is time. Our model was perfect; Time made it wither.
Business demands innovation and the expert knowledge of today is the antiquated ramblings of tomorrow. So how do we model a Domain built on sand? I'd argue the typical Domain Drive Design approach is to lay a bedrock of Domain Expert driven ubiquitous language, from this bedrock comes the choreography. Confident in our assumptions the Rich Domain Model is viewed as malleable to whatever the business demands. But it was the expertise of the Domain Expert that shifted. New ideas, optimizations, approaches and evolving definitions all crash though our model tearing down the house of cards. So what then? We build it again? Based off our latest snapshot of a Domain Expert? How can something so malleable become so rigidly orchestrated?
Well maybe we just missed something.
Reflecting
Our Domain Model was built as an expression of an instant of time. That is the key failure; we represented the Domain Space in a snapshot. Just as a picture is out of date as soon as it's taken, our model is growing stale even as it's implemented. That's is the salient point; our model ignored time.
As engineers we have to recognize that our Domain Experts don't deal in code, they don't get heated about anemic vs. rich models, they don't run their own K8's cluster at home. A Domain Expert squeezes the most defined Success possible out of a given Domain. And every noun in the preceding sentence is subject to evolution.
What we typically resort to is a Domain Model, but this is a singular noun describing an instant in time. As engineers our expression medium, code, allows us to transit time effortlessly. Therefore our model has to be evolved to capture the business value we're after. In order to capture the true business value of the Domain Expert we need to capture the Domain Space and the Evolutionary Operator on that Domain Space.
Redefining
To make progress, as engineers, we stand on our definitions and define our key concepts.
- Domain Space: A vector field defined by the degrees of freedom of its constituent nouns and verbs
- Evolutionary Operator: A function that evaluates a point within the Domain Space
- Domain Expert: An Evolutionary Operator on a Domain Space.
- Domain Model: A point within a Domain Space.
These were likely not the definitions you had in mind! But through the lens of these definitions we see our Domain Model as woefully inadequate to describe what the business is trying to accomplish. Representing a single point within our Domain Space is certain to fall victim to the fate we've described above.
Taking The Plunge
Preamble
You won't see code examples here. Code is the hammer we forge our iron concepts with. Whatever your language, whatever your technique, whatever your paradigm; the concepts are what gets forged into business value.
Domain Space
You might ask, "I've made it this far, now what the hell are you talking about?"
A vector field is is the assignment of a vector to every point within a set whose structure is defined by its constituents. These constituents are defined by their degrees of freedom; the axis along which they're allowed to change.
By simply defining the nouns and verbs within our Domain Space we start to imply constraints, i.e thing X can change along axis Y. We define nouns in terms of change vectors. Our verbs interact with the nouns and link them in nearly infinite combinations forming networks. Doing this exercise brings our Domain Space alive and allows us to see what Domain Models can be produced. The possibilities become nearly infinite! Time and all other axes are integrated into one holistic picture.
Evolutionary Operator
We define an Evolutionary Operator that works against our defined Domain Space with the critical guidance of our Domain Expert. Remember that the Domain Expert is there to squeeze out success but their expertise is at a point in time. Instead of capturing this expertise in a static Domain Model, we dig deeper. We conceptualize the Domain Expert's expertise as a function evaluated against our Domain Space that yields a Domain Model.
Each evolution of the Domain Expert yields a different Evolutionary Operator and when applied to our Domain Space it yields a new Domain Model.
What Have We Gained
In this exercise we have stressed the importance of defining a Domain Space. A broad malleable space that represents the context of your business is key. Remember when defining this, your not capturing the state of the Domain Experts view yet, your capturing the real world physical variability and time dependent evolutionary vectors of each noun and verb within your Domain.
Finally
By modeling a Domain Space you create a nearly infinite amount of Domain Models. Each point in a Domain Experts evolution can yield an executable Domain Model derived from the Domain Space.
It's this evolutionary robustness the differentiates a Domain Model from a Domain Space.
Just food for thought we you design your next project.
