[tech] Domain Driven Design

Domain Driven Design (DDD) is a book by Eric Evans, known as “the blue book”, which provides a broad framework for making software design decisions and a vocabulary for discussing domain design. The original book was published in 2004. In this article I'll provide a summary of some of the ideas. However I am going to primarily use a modern derivative book Learning Domain Driven Design published in 2021 and use some references to talks and references for this article.

Software complexity

Software is eating the world. Businesses are progressively trying to solve more complex problems to meet their customers requirements. Software engineering is hard by itself. To successfully ship software, a team needs to have the correct technical skills and be able to deliver and maintain a solution. In many respects, making sense of new business domains can be far more challenging than producing the software. This is especially true in enterprise software where you are not necessarily a user of the software. Enterprise requirements typically also have many business rules that are often in conflict with each other. Failure to grasp the business domain results in suboptimal business software which is why many software projects still fail.

DDD is a software design approach that focuses on modeling software based on business requirements by better collaboration between the domain experts and software architects. A shared understanding of the business problem and software solution across the different stakeholders is key.

DDD design is broken into two parts - strategic design and tactical design patterns

• Strategic design covers the why and the what of the problem
• Tactical design is about how the various technical components are implemented.

In this article I'll focus on strategic design aspects and skip tactical design patterns.

Problem space

The problem space that a business addresses is the domain of the business. Like a retailer sells goods, a coffee shop sells coffee. The DDD definition of domain is-

Domain - A sphere of knowledge, influence, or activity. The subject area to which the user applies a program is the domain of the software.

To achieve its business domains' goals a company operates in multiple subdomains. These are a finer area of business activity. For example, even for a business that sells coffee, it needs to solve primary concerns like procuring coffee, making coffee for customers, and also a billing system, marketing systems and much more. A large domain can be broken into smaller subdomains. The three types of subdomains are - core, generic and supporting.

• Core subdomains provide core business value and are a competitive advantage. These are complex. Implementation is in-house and the problem area is interesting for the business.
• Generic subdomains are business activities that all companies perform. However they are complex and hard to implement. These problems do not provide any competitive advantage and implementations are outsourced by buying or adopting solutions.
• Supporting subdomains are low complexity and low differentiation. These may be in-house implementations or outsourced.

Subdomains typically manifest as a set of related use cases. These can be by the same user persona, or similar data being manipulated.

Domain experts are subject matter experts who know the intricacies of the business that needs to be implemented in code. They understand the final user requirements. In some companies, product managers act as domain experts based on interviews with users.

Models

For visual learners, watch a presentation on "What is a model?". DDD defines it as-

Model - system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain.

A model hides complexity (and reality) by omitting unnecessary details. A good model should make it possible to express the core use-cases for a domain well while other use-cases might be difficult or even impossible to solve. It distills knowledge and assumptions of the domain.

Solution space

To be able to build software; the problem subdomain needs to be expressed and understood by a common ubiquitous language by all team members. Often it is not possible to have a single term across the entire domain. For example, an account might be able to model a login interaction. Another representation of the account might be required for a visitor to the site or a friend in a social network. Hence based on the subdomain, there are different ambiguous or synonymous terms possible.

A bounded context is a description of a boundary within which a particular model is defined and applicable. The model aka language is ubiquitous within this boundary or scope. Within a bounded context each term has a singular well-defined meaning.

Watch this video on bounded contexts for a sample exercise.

Strategic design

The problem space or domains are discovered. These are learnt based on requirements. On the other hand, bounded contexts are designed. Choosing the boundaries is a strategic design decision based on how we choose to address the solution. Each bounded context is meant to be implemented as individual systems owned by separate teams. The book recommends ownership per bounded context along with interaction mechanisms since there are real interactions across various systems. The DDD concepts do overlap with Team topologies concepts. By splitting the larger domain into independent bounded context solutions, each system can independently evolve and adapt to future requirements.

As mentioned, various systems need to communicate to solve for the larger domain problems. There are communication patterns at the edges of the bounded-contexts. A context-map shows the integration patterns across various bounded contexts. This can be used to show high-level design and technical communication patterns. If the integration patterns across a couple of bounded contexts is highly coupled then it is likely that the teams that need to maintain these are going to also need to work in collaboration mode (from team topologies interaction modes) impacting overall velocity.

Design patterns

The rest of the book explains various strategic patterns related to collaboration across bounded contexts. These include-

• Co-operation - partnership and shared kernel
• Customer-supplier - conformist, anti-corruption layer, open-host service, published language
• Separate ways
• Big ball of mud!

Event storming is a workshop methodology that helps brainstorm the domain and bounded contexts. Another video should explain the process.

DDD today

I'll add a personal note on how I think the DDD book is still relevant today. Although the DDD book is fairly old by tech standards it does address a fundamental concern - breaking the barrier between business domains and software design by effective communication.

In the space that I work with we have many subdomains owned by our organization and hence multiple complex solutions. Keeping track of the current systems and charting out their future state requires many individuals from various functions to collaborate across many sub teams. Often we have a clash of terms since the bounded contexts are not explicitly declared. These issues multiply as we keep expanding our scope of work and integrating with other platform and product services.

I've often had conversations with other team members on the complexity of some parts of the software systems. A software solution cannot be simpler than the business problem that we intend to solve. However, using effective methods, it should not be drastically more complex either.

DDD is not for everyone. You should not adopt architecture processes for their own sake. Favor people over process and use these tools if your organization needs it. Having leadership and appropriate stakeholders buy in to make sure that artifacts and processes are maintained is also critical.