This is the first of a 2-part series about the Domain. The second instalment, “The role of Domain Coach”, will be available next week.
People in the software business are used to hearing about the Domain. Surely, not putting it on the spotlight, for the Domain is used more as an instrument to provide some background and structure in our work, but the word is definitely popping up from time to time in conversations. And yet, to get a concrete definition of what the Domain is can be a pretty disappointing experience.
Indeed, what do you think the Domain is? My experience is that asking the very same people who are creating software allegedly by the Domain only produces at the very least iffy answers. Surf the Internet for examples.
One of the most cited definitions for the Domain is this one, given by Eric Evans in its 2015 book “Domain Driven Design Reference: Definitions and Pattern Summaries“, which is actually repeating, almost word by word, the definition given in its fundamental book of 2003:
A sphere of knowledge, influence, or activity. The subject area to which the user applies a program is the domain of the software.
Eric Evans, Domain Driven Design Reference: Definitions and Pattern Summaries (2015)
According to this definition, were you, let’s say, producing software for the Accounting Department of an organization, then the Domain would be “the sphere of knowledge of accounting“.
Other people, though, would object that the Domain has nothing to do with the real world. For them, the Domain is the collection of abstractions that facilitate our job to produce and maintain software applications, abstractions that we model out of someone’s knowledge about accounting, but which have far less to be with accounting and a lot more with software.
Under this alternative vision, the Domain would be a collection of designs, a bag of models.
Generally speaking, a model is a representation of something else for whatever purpose you have in mind. A picture, a sketch, a diagram, are examples of models. Therefore, what the supporters of this alternative definition say is that developers pull out models of reality to represent that reality into their applications, and so it is quite appropriate to say that those models are created purely on a practical convenience.
So, is the Domain a container of our knowledge about the world? Or, strictly speaking, about a part of the real world that we sliced from it? As software developers, we will model that slice of the world in our code. Is the Domain a container for our models of that slice of reality?
Towards a (better) definition of the Domain
The key to escaping this tangle is to realize that the Domain as a container of knowledge is something that is given to us, whereas the Domain as a container of models is something we created.
Bearing this pretty apparent distinction in mind, if only for clarity’s sake, why not give them a different name? And, since it seems reasonable to consider the slice of reality, and therefore our knowledge of it, a necessary antecedent for making models (representations) out of it, why not call them respectively Domain and Codomain?
Of course, we could use alternatives. In Cartography, for instance, there is a name for the collection of all maps, or charts, of the Earth. It is called Atlas. This same name is used in Classical Astronomy to refer to the collection of all maps of stars. As a gathering of all our models in the Codomain, Atlas is not a term that I would love, though. Maybe Codomain is enough?
There is plenty to say about the Domain and its Codomain(s). Some of the most outstanding features are:
One for all, and all for one
There can be plenty of Codomains mapped to the same Domain. No matter the Domain, every team would rely on its own background, skills and context to pull out their own models. In a way, we may say that the Domain is a story and the Codomains are the version that every team compiles to tell it.
Alternative versions of a given Domain might be even fairly equal in terms of technical efficiency. To illustrate this, let’s imagine a Subscription-based business, and let’s say that Subscriptions are paid in 1-year terms so that they must be renewed afterwards. We may model this Domain defining a Subscription Entity as the result of someone successfully paying its price so that every renewal produces as a result of an all-new Subscription entity.
In the oversimplified version of this Codomain, any given client may have N (≥ 1) Subscription instances, which may also have M (≥ 1) Payment instances. Interruption of payments by the client would just fit this model perfectly.
Or, we may design our Codomain with the spotlight on the rights entitled to the Clients by their paying for one, and only one, everlasting Subscription as many times as they’d want. There could be M (≥ 1) Payment instances too, but only 1 Subscription per client. The use case of clients interrupting their Subscription would require a kind of deactivation/reactivation feature to be implemented.
In my opinion, the Domain of any Subscription-based service would be well represented by any of both alternatives. Further inspection of the Domain, cultural bias in the organization, or personal preferences of the team members, might advocate for one Codomain over another. What really matters is that the chosen option turns comprehensible for the people who will handle it.
Often, in scenarios wherein a legacy application is in process of being replaced by a new one sharing the same feature goals, two Codomains mapped out of one same Domain will coexist. Which brings us to the following item.
Different paces of change
Society, Economy, and Laws do change, but obviously not as fast as software applications do. Any changes in the Domain will get their expression in the Codomain through adaptations in its models. Yet, the vector of change coming from outside of the Codomain run at a moderate pace.
There may be many reasons why Codomains change or even get replaced by a completely new one. For example, new features or improvements in the existing ones might be so tough to implement that full redesign would become the only feasible option. Or, the neverending conversation among the members of the team, and their own professional evolution, may compel them to seek different approaches to solved problems.
A language we must learn, and a language we create
In human organizations, human language is the default tool to communicate knowledge. In the context of the methodology known as Domain Driven Design, there is a name for the dictionary of terms that people use to speak about the sphere of knowledge that we call the Domain: the Ubiquitous Language (UL).
The words in this dictionary are adopted, and their meaning transcribed, in the models that inhabit the Codomain: Entities, Value Objects, properties, methods, or functions. As a general rule, the transcription of terms from the UL to the Codomain is not unique: they appear in several models in the form of partial representations. Let me illustrate this with an example.
Let’s say that the UL contains the term Customer to stand for organizations or individuals who started a business relationship with our organization. In the Domain, Customers have a lot of properties, and surely they participate in a lot of user stories. Some of these user stories are related to Sales. To model them in our Codomain, we will collect those elements in Customers that are relevant in the context of Sales, and will ignore the rest.
Similarly, Customers are also represented in the context of Accounting. To model them there, we will pick the elements in the Domain that are relevant in accounting, whereas the rest are simply ignored. Certainly, some elements in Customers will appear in our models for Sales and Accounting, for example, their name. Yet, the simple fact that they both are different will be explicitly visible in the elements only present in one of them. By the way, we could define a measure of the distance between models in the Codomain by counting how many elements they have in common.
The transcription of language from the Domain to the models in the Codomain is not an easy topic. I’ll say more about the UL and the gnarly relationship between the Domain and the Codomain in the second part of this series.
Without the Domain, software applications based on the collection of models in the Codomain can work, but it is because of the Domain that software applications make sense. And so, it is thanks to the transcription of meaning from Domain into our models in the Codomain that the code we write becomes comprehensible, and ultimately what enables us to elevate our applications to its most perfect form: software that tells a story.
The difference in nature between the Domain and its Codomain(s) was already present, though implicitly, in the definition given by Eric Evans in his books. For him:
- The Domain refers to what our software is about.
- So that, when they run, software applications yield something back to the Domain.
Strictly speaking, the definition of Evans refers to the Domain as a collection of knowledge. Although, if we hold straight on both statements above, the Domain also stands for that part of reality that is impacted by the software when it runs. Hence, the Domain is not just a slice of the world that we took as the starting point of the process of designing a software application, but also that part in the world that gets changed by the action of software.
Paraphrasing Carl Sagan when he talked about us and the Cosmos, software is a way for the Domain to act on itself.
A Multiverse of Codomains
If the Domain was a Universe, then its virtually infinite collection of Codomains would be a Multiverse. Every alternate Universe in that Multiverse is a representation of the Domain written in code. Some of those Universes might be just slightly different, whereas others might show a vast number of alternative ways of representing that same Domain. All of them, a dynamic collection of hundreds and hundreds of lines of code, changing with every commit, and evolving at their own pace to an uncertain future, living a life which spans no one knows for how long.
The story of the Domain, and its multiverse of Codomains, continues in the second part of this series: The role of Domain Coach.
Picture copyright note: a modified version of a Roy Lichtenstein’s painting I just took from the Internet.
how possible 