We slap fancy names on things in Software Engineering; in fact, it is almost a requirement (and some of those names can be unhelpful— work at any large-scale organization and you’ll start hearing names like “Voltron” and “Scorpion”). The problem is: those names are either [1] not descriptive of the actual purpose; or [2] intimidating. Add to those names tomes of information and we leave any curious person with the perception of impenetrability.
Thankfully, Domain-Driven Design (DDD) doesn’t quite fall into either of these categories; but the words do leave the question, what is it, really? First, let’s unpack the term “domain.”
Today, “domain” is commonly used to refer to a segment of a web address. But, when it comes to DDD, that’s not what we mean by “domain.” “Domain” in this context refers to a business domain. A business domain is the company’s overall area or areas of activity.
From there, the term “domain” quickly ramps up in complexity. Some businesses start using words like “vertical,” “organization,” and “line of business” — all intended to refer to a grouping of people or concepts that address a perceived market problem. Each of these terms is potentially a domain (or subdomain). A domain-driven design, then, is a design of some sort (communication; organization; software; architecture) that is driven by the very specifics of a particular business activity.
In a recent seminar led by a key contributor from the DDD Crew, I quickly realized the process of arriving at a domain-driven design is critical and necessary for making comprehensive and meaningful changes. The necessity lies in enabling an organization — across all departments and business areas— to arrive at a common, shared understanding of the business problem (more likely an understanding of a multitude of problems). The resulting consensus enables a business to more easily expose hidden issues and identify opportunities.
Ultimately, the process results in the ability for us — the business — to do a litany of things, all of which ultimately result in cost-effective and performant organizations and systems. In this article, I hope to get to some of the why for Domain-Driven Design.
When is Domain-Driven Design necessary?
For clarity: there are multiple parts to the DDD process. The part most germane to a broader business audience — and to this article — is the part largely focused on domain discovery called “event storming.”
Let’s pause on that term for a moment: domain discovery.
You might assume a business operating in a particular market knows its business domain — and it very well might; however, “domain” is not exclusive to the external domain of the business. Likely, in addressing a single market, a business is comprised of multiple domains or subdomains, internal and external.
I might list “Human Resources,” “Sales,” “Engineering,” “Operations,” etc. as examples of domains within a business. This list isn’t sufficient — and potentially even damning. As a business scales, these traditional internal domains may even become debilitating — debilitating because the scaling business has likely departed in function from these traditional organizational boundaries. As a result, communication is stifled, systems are over encumbered, and change becomes slower, more inefficient, untargeted, and uninformed. In short: the organizational structure of the business no longer matches what is needed to drive impact.
Enter Domain-Driven Design.
Domain-driven design enables a business to discover what domains actually exist and, ideally, to act on those discoveries organizationally and — from a technical perspective — architecturally.
How does DDD [start to] solve this?
The domain-driven design process begins with business domain discovery. There are a few techniques for doing this analysis but a popular one, “event storming,” has two objectives (among others)…
- Defining exactly what boundaries do and should exist in the business
- The ability to understand or map the competitive advantage of those domains
This understanding will then determine where resources and efforts should be spent.
So, what problem does domain-driven design attempt to solve?
A business will likely have assumptions about how it operates. DDD’s event storming process has a radical goal: democratizing the definition of what actually happens. Regardless of scale — departmental, organizational, company-wide — event storming seeks to get everyone in the same room.
Understandably, the Junior Software Engineer may have a radically different perception of what is happening than the Director of Customer Support; event storming gets these people in the same room and physically maps out that perception. This exposes misunderstandings, true actors, pain points, strengths, edge cases, and sometimes it exposes things completely unknown to a business.
The focus of event storming can be as topic-focused as needed, but ultimately asks a simple question: what is actually happening? Often the answer directly contrasts a business’s assumptions about the relevance of its existing domains.
A successful event storming session results in a very concrete and specific analysis of the business and its systems. Importantly, it does this in a language that is accessible, meaningful to everyone, and reusable. We aren’t talking about Annual Recurring Revenue, Capital Expenditure, or Dependency Injection. We are talking in a simple, plain-to-use language that can be shared across work streams.
What is Domain?
As we engage in the event storming process, responsibilities emerge — and often groups of them; these responsibilities fall along the actual lines of communication within a business — or, at least, more optimal ones.
Domains — groupings of people or concepts that address a perceived market problem — then become defined by communication-based areas of responsibility; the distinction between a domain often being the point at which a critical transfer or hand-off of information or responsibility reasonably occurs.
The DDD process provides a format for challenging our existing understanding of the domains that make up our business and doing so by starting at the very beginning: baselining our understanding across the business using simple, easy-to-use language. By doing this, we can offer a clear definition of the domains that make up a business and better align solutions to meet those needs — and do so without wasting resources.
What next?
There is so much more offered by the DDD process — so much more than can be captured in a short “pique your interest” introduction; if you are curious about what it looks like, I encourage you to do one of three things:
- Check out the DDD Crew’s free repository. I can attest from personal experience that these people are phenomenal.
- Read a book or subscribe to a blog! Similarly, there are some awesome people talking about this.
- Reach out to us! We’d love to talk about setting up a session with you to help you understand whether DDD is the right process for your business.
