What you need to know - Strategic Design
Domain Driven Design (DDD) is an approach to designing and building software where the focus is on accurately expressing business rules in isolation from other technical concerns such as persistence of data.
Unfortunately DDD is famously daunting to newcomers, in part because there are many unique concepts to learn. In this article I will briefly introduce the important ideas so you can confidently continue on your DDD journey.
Part one will focus on concepts that are relevant to everyone involved in software development, not just developers. Part two is specifically for the coders, but feel free to check it out anyway!
“I’ve only got one minute”
If you only take two things away from this article, at its core DDD advocates for:
Model Driven Design
Modelling business processes and rules in self-contained Domain Models* is the top priority. Everything else from database design to architecture are secondary considerations.
Ubiquitous Language
Everyone involved in the development lifecycle should communicate in the language of the domain/business as it is used in a particular context. Ideally, some lightweight and accessible documentation of the Ubiquitous Language is maintained.
Strategic and Tactical Design
DDD consists of two related disciplines: Strategic Design and Tactical Design.
Strategic Design relates to the big picture: understanding the problems a business must solve; where it achieves competitive advantages; the relationships between teams; and with all this in mind, what software to build.
Tactical Design refers to patterns, tools and practices that make it simpler to build helpful Domain Models. We use Tactical Design when we have complex business logic to model or when complexity may be introduced in future.
In essence, Strategic Design is about determining what we need to build. Tactical Design is about how we build it.
Ubiquitous Language
Underpinning both Strategic and Tactical Design is the idea of Ubiquitous Language. This is an unambiguous, well-defined set of terms that closely mirror the language used in a business context. Consistently using the Ubiquitous Language in conversations, requirements, and code, removes the overhead and errors associated with regularly translating from dev-talk to business-talk. An entire book could be dedicated to this subject, so I suggest doing some further research on this important topic!
Problem Space and Solution Space
Imagine a company that offers outsourced warehouse operations as a service (WOaaS). It’s ‘special sauce’ is how it manages warehouse inventories, but it also needs to make sales, advertise, track timesheets, and more.
Each problem area can be described as a Subdomain. A simplified Problem Space map for the WOaaS company might look like this:
Figure 1: A simplified map of subdomains / Problem Space
Identifying the problem areas in a domain is called Problem Space Analysis. This requires close collaboration with Domain Experts, the people who know the business best.
Mapping the Problem Space to the ‘as-is’ enterprise architecture yields the Solution Space.
Figure 2: A representation of ‘as-is’ Solution Space
Next, we want to determine a more desirable Solution Space. To guide us, it is helpful to reflect on one of the consequences of Ubiquitous Languages.
Bounded Contexts
In our example, a legacy system attempts to address several problem areas. Despite the best efforts of talented individuals, it will probably suffer from high defect rates and maintenance costs for a simple reason.
In each subdomain, words and phrases have specific meanings. A code base with colliding terms necessarily forces team members to create a new, ad-hoc language which must be translated into business language. Inevitably, this leads to bugs, misunderstandings, slow onboarding, tribal knowledge, and a myriad of other problems.
By attempting to create software that fulfils the needs of several subdomains our models become bloated, confusing and ambiguous, causing performance issues and spiralling complexity.
Strategic Design suggests a separate system per Subdomain. We can describe these systems as Bounded Contexts, within each there is an unambiguous Ubiquitous Language.
Now, back to the WOaaS company. How do we determine what would be a more desirable ‘to-be’ enterprise architecture? What should we build to achieve the best outcomes for the business?
The Core Domain
The most investment should be put into the subdomains where the business creates a competitive advantage, the Core Domains. In our example, this is the Inventory subdomain.
A Bounded Context should be created for the Inventory subdomain and the best possible team should be built out to work on this.
Figure 3: A simplified map of the ‘to-be’ Solution Space
The other subdomains are referred to as Generic or Supporting Subdomains. While crucial, no matter how ‘beautiful’ the Invoicing system is it will not differentiate the business from the competition. Systems covering these subdomains may be candidates for commercial, off-the-shelf products or outsourced development.
The Core Domains merit the greatest investment and the full power of DDD’s Tactical Design… which you can read about in part two.
*Domain Model: Code that purely describes the behaviours, properties, and interaction of things relevant in the business context the software serves. It is entirely ignorant to concerns such as runtime environment, persistence, hosting environment etc.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
