This is the second instalment in the 2-part series about the Domain. The first part, “But, what is the Domain“, is already available. Please check it out.
Closer alien worlds
The first volume of Brandon Sanderson’s fantasy epic The Stormlight Archive, titled “The Way of Kings“, opens with a very powerful scene. One of the characters of the saga, Kalak, while wandering across a battlefield, stumbles upon the corpse of an enormous beast of stone, a thunderclast, lying there dead. In the world of Kalak, there are people with magic abilities, flora and fauna that look and behave in ways unknown to us, and climate phenomena that follow different patterns than those on Earth.
Those magic abilities, animals, plants, even ghost creatures, besides the tremendous weather events, are constituent elements of the world where the characters of the books live. No matter how alien to us those elements might be, for them, all these elements are not alien at all, but fundamental constituents of their reality. For its inhabitants, this world makes perfect sense.
The true fact that readers, who are visitors from another planet, can experience this consistency is remarkable, though far from accidental. It is the outcome that defines what a good writer in the fantasy genre (as in any other genre) is.
We do not need to get struck by events of such an emotional resonance as we find reading books, watching movies, or TV series, to experience this weird and, at the same time, consistent strangeness. The same effect happens when we visit the ruins of ancient civilizations. On a minor level, this happens also when we travel abroad, or enter foreign communities established nearby. Some times, we experience a culture clash. Other times, we simply got fascinated, mesmerised even. This feeling that all these close encounters bring to us is the experience of moving across contexts.
These experiences give us a rough understanding of what a context is: collections of all kind of things (flavours, words, images, facts, etc.) which we can draw an imaginary boundary around. In a way, it is like the whole reality was divided into imaginary, self-contained bubbles that related among them in multiple ways, and which we are allowed to visit, or where we may be staying for long periods in our lives.
Why do contexts matter? Because words meaning depends on the context wherein they are utilized. For example, in the context of Surgery, an operation stands for performing some kind of invasive procedure. In the context of the Army, an operation can be defined using exactly the same words, and indeed it refers to an invasive procedure too. However, they both are very different in fact, as it is their outcome.
In the software community, contexts have an alternative name: Domain. For example, teams dealing with an application related to Taxes, or to Recruitment, would say that they are working in the Taxes Domain, or the Recruitment Domain, respectively. And, as it happens to new readers of “The Stormlight Archive” books, so developers who were alien to Taxes before they started working in an application to handle them, would eventually become able to handle Taxes stuff and make a sense out of it.
More specifically, for the people involved in the creation of software of any kind, the Domain stands for:
- A self-contained sphere of knowledge; for example, Taxes, Reservations, Grape Harvesting, etc.
- That part of the real world (that imaginary bubble) wherein that knowledge is applied and is affected by software applications running on it.
According to these two properties above, a proper definition of the Taxes Domain for people working in a taxes software application must be way more concrete than just “Taxes“. It should be something like this: “Our software application is about Taxes applicable to the gaming industry in the country where this organization has its tax residence and wherever it has clients“.
Representing the Domain in Codomains
The first step for software applications to have an impact on their Domain is to represent the knowledge that defines what the Domain means in the code. This representation is what I called the Codomain in the first part of this series. Please refer to it for further details on the special bond that links the Domain and the Codomain.
Any given Domain can be represented into multiple Codomains. There are several reasons for this. Every team has its own approach to software design, based on the background and skills of its members and the team dynamics among them. There is also an inherent complexity in the task of representing knowledge (remember this part of the definition of the Domain above?) in models. And there is also the fact that human comprehension of reality is incremental.
This means that, in practice, Codomains are never completed, as they evolve with the team’s increasing understanding of the Domain, and that very different Codomains can very well serve their purpose.
Some times, even alternative Codomains may coexist for convenience. For example, an old version of the code is kept up and running for some clients whereas, at the same time, an all-new version of the same application, developed out of a new representation of the same Domain (i.e., a different Codomain), is delivered to another collection of clients.
All this variability strongly suggests to me this metaphor: if the Domain was a Universe, then the whole set of Codomains that represent it would constitute a Multiverse. An ever-changing Multiverse of software that, when it runs on that slice of our world (remember this second part of the definition of the Domain above?), drives change into it, giving shape to our software-driven world.
The practice of creating Domain-driven software
Not all the software code is written out of an explicit representation of a Domain. The Evans Data Corporation Global Developer Population and Demographic Study results for 2020 say that the global population of developers rounds the 27 million people, which suggests that the total number of people involved in the creation of software with any role exceeds 50 million. To expect such a consensus in any methodology would be ridiculous.
In the variety of existing methodologies to create software, Domain-driven methodologies are generally considered as being best suited when complexity is an element you cannot neglect, a territory where they have proved themselves pretty successful. These methodologies, such as the Domain-driven Design, put the Domain explicitly in the centre. With them, plenty of organizations have been able to create, deliver, and operate software that matches user expectations, is easier to maintain, and can change at the business pace.
Releasing the full potential of Domain-Driven methodologies is tough, though. Certainly, successful business cases motivate many organizations to embrace them. Unfortunately, too often that is a journey that teams walk alone: they learn a few from instructors and materials, and a lot from themselves spending time puzzling out how to make general practices work in their own context.
I came to believe that there is a better way to help teams make this path less steep. Including someone, a new role indeed, who, instead of instructors or consultants that come, do their thing and go, belongs to the team. A person who knows about the team and the organization and hence is capable of road mapping the way that fits them best.
I call this cicerone the Domain Coach.
Exploring the role of Domain Coach
There are plenty of techniques in the realm of Domain-based methodologies. Everyone has its own pros and cons, and it is not feasible for people in any development team to spend their time exploring, evaluating, and learning all this broad ecosystem of techniques. Here enters the Domain Coach.
As a facilitator role, the Domain Coach does indeed not produce code, but she definitely helps the team do it by providing them with guidance and techniques. Let’s describe a bit what the goals of a Domain Coach would be:
The Domain Coach leads the conversation around the Domain
The first and foremost task of the Domain Coach is to organize and lead the exploration across the business that nurtures the Domain. Especially when the teams start working with Domain-driven methodologies, picking the right Domain to start is critical. It should be illustrative, not too complicated, and yield visible value for everyone no matter their role.
A common way of exploring the Domain is organizing cross-functional Working Groups. Each Group will approach one specific topic. These Working Groups are absolutely bespoke: the Domain Coach will gather them when necessary and will dismantle them as soon as their Domain exploration concludes. If the Domain is particularly important for the organization, or when the exploration is scheduled in phases, these Groups would stay longer, until the Domain Coach eventually decides to dismiss them.
The Domain Coach must pick the members of every Working Group accurately and set the policies that will rule their work. Likely, she will need to watch internal politics and hierarchy power relations within the organization. However, handling Working Groups governance is not one of her goals: it is an instrument she should be ready to give in if doing otherwise could jeopardize the main goal which is to help teams produce better software.
Leading the conversation about the Domain also means that the Domain coach is the central point of communication about the Domain. She is the ultimate source of truth about the Domain and so she must keep the right, cleanest record of it. She must enforce its consistency and prevent corruption due to misuse, lack of comprehension, or even appropriation for spurious reasons by anyone in the organization.
In Domain-driven Design the main instrument to keep a record of the Domain knowledge is called the Ubiquitous Language. At all effects, the Domain Coach will be its managing owner: the contents come out of the Working Groups, and the Domain Coach is their ward and main communicator.
The Domain Coach watches the governance of distributed rights
The multiple software components that organize complex software application ecosystems do not run isolated. There are several possible levels of cooperation among those components, each one with its own rules of sharing information and of controlling the conversation between the participants: what information should be shared, how to name every piece of it, how to structure them in a given format, etc. Who would make the final decision? Would it be the fruit of a consensus or is one of the teams going to define the shape of the contact surface between the components?
The existence of valid alternatives to implement this integration among autonomous software components implicitly grant political rights to the development teams responsible for speaking on behalf of each component: who defines what, and how, which information is shared; who can initiate, and stop, the conversation; etc. The Domain-driven Design methodology, for example, lists up to nine options, every one of each fits some circumstances better than others.
The Domain Coach realizes and governs those political rights, and so she becomes responsible for setting the proper policies to guarantee that discussions between teams are respectful and lead to well-balanced decisions. Hence the Domain Coach must cooperate with the other managing roles in building a healthy ecosystem of distributed development teams.
The Domain Coach supports in modelling the Codomain
Not all that is in the hands of the Domain Coach refers to governance. On the ground level, she also participates in the modelling sessions that, starting from the Domain, will produce a representation of it ready to be written in code. The Domain Coach would participate in these modelling sessions as a supporting participant only, for example, to provide supplementary information or clarify what is the right meaning of any of the terms in the Domain. Depending on the maturity of the team, and her seniority, she might also have a voice in how to shape the Codomain.
There are multiple choices in the set of modelling techniques, as there is also plenty of room for heuristics: some techniques would suit some teams perfectly, whereas others might not work at all. Even though the Domain Coach should advise and make sure that the development teams receive the proper training to make informed choices, she should not be expected to be the sole trainer and expert in all these techniques.
Coda
This blog claims that there are better ways to create software, that their outcome is also better software applications, and that is possible to enjoy while gaining both goals. I have got the opportunity to see Domain-driven methodologies in action and used them extensively these past years. They work. Yet I am afraid that fulfilling their potential requires more than dominating the techniques: a bespoke role with the background and skills needed to navigate the organizational noise, set fair rules to everyone involved in producing software, and ensure that everyone is trained and entitled to participate. In a word, be accountable for the realization of that potential.
That role would be the Domain Coach.
Picture copyright note: Photograph from the web site of the Mori Building Digital Art Museum: teamLab Borderless, in Tokyo https://borderless.teamlab.art/
how possible 