Pulling Together

Domain-driven design (DDD) is a software development approach that develops a domain model – an abstraction of the behavior and data of a system – and refers to the entire design of the software, from the code level to the architecture, and the interaction of the development teams involved. For a consistent domain orientation to work, everybody involved needs to exchange information, especially technical experts and developers.

Ultimately, domain strategies can only form the basis of development if all stakeholders communicate them clearly; otherwise, only the subject matter experts have the required detailed knowledge of the domain – not the developers. This point is exactly where the first tie to agility can be found. One of the 12 principles of the agile software development manifesto includes: "Business people and developers must work together daily throughout the project" [1]. This arrangement is the only way to implement a domain-driven design.

Practice Instead of Theory

Initially, the DDD movement mainly encompassed ideas on structuring code or software systems. Discussing these with subject matter experts is difficult because they often lack the technical background to do so. Concepts like classes and modules are simply not general knowledge. However, it cannot be a prerequisite for joint work to first train subject matter experts in this area – the bar is simply too high. DDD, however, now includes a host of collaborative modeling techniques. The objective is to strengthen the understanding of the domain through joint work on artifacts that are not used directly to structure the software but serve solely to explain the domain in more detail.

Event storming is a well-known example of collaborative modeling, wherein everyone involved in the project uses sticky notes to create complex business processes [2]. Each sticky note contains an event from the domain (e.g., Order received ) that clarifies the process flow. In practice, the method even works for more complex processes; you just need enough space for the sticky notes.

Because the idea is not particularly complicated at this level, everyone involved should be able to write a couple of sticky notes. Later, more information can be added on additional sticky notes of different colors. Another technique with the same objective – visualizing the flow of a business process – is known as domain storytelling [3]. In this way, DDD adds concrete techniques to the agile idea of collaboration between subject matter experts and developers.

Forced Iterations

DDD aims to establish a model of the domain in executable code. The logic in the code reflects the facts (e.g., calculating the cost of a delivery or its current state). In doing so, DDD assumes that despite all efforts, this model will never be perfect, as Eric Evans wrote in 2003 in one of the first books about DDD [4].

At its core, the teams' role in DDD is to understand the subject matter (knowledge crunching), which is underpinned by a learning process that takes time. Accordingly, the model in the code exclusively represents the developers' current understanding, with all the errors and inaccuracies that entails. The challenge in software development is not programming the code, but understanding what to program.

The model in the code cannot ever be perfect because the subject matter changes. If business processes change, you need to adapt your software. Conversely, introducing software influences the facts. If you engage with and reflect on the facts as you model them, you are likely to identify an optimization potential that could be lost in the daily grind. To take advantage of this potential (e.g., automation), you need to change both the business facts and the software.

If the business facts change during development, you respond to these changes with a new iteration (i.e., a new version) of the software. To ensure that everyone learns, you need to make the software available to users after each iteration. Developers discover new details of the business facts, and subject matter experts discover new optimization potentials. Therefore, one of the core elements of agile software development is developing software iteratively and incrementally. These conditions are required for DDD and knowledge crunching to work.

Prioritization

Relationships between agile values and DDD can be found in other areas, too. For example, the principles of the Agile Manifesto state that the highest priority is "to satisfy the customer through early and continuous delivery of valuable software" [1]. Typical agile processes comply with this principle by having domain experts prioritize features, which allows the principle to be implemented without affecting the structure of the software or the code.

Domain-driven design complements the core domain concept and refers to the area of a system that implements the motivation of the project, which sets it apart from generic subdomains that do not allow for differentiation. A core domain can be a product configurator, which gives the company a unique selling point compared with its competitors. An example of a generic subdomain could be invoicing, which although it is equally important because, without invoices you have no revenue, it does not further the cause of differentiation.

Core domains and generic subdomains break down the value of the software in the structure into more and less valuable parts of the software (Figure 1). The distinction between a core domain and generic subdomain is based on a simple observation. Obviously, not all parts of a software system have the same quality, on which basis you have only two courses of action: Either you leave quality distribution to chance, or you actively control it. If you decide to take control, you need to know which parts need to be particularly good, which is exactly where the core domain comes into play: You accordingly pay attention to the highest quality and create a competitive advantage in the process.

Figure 1: The product configurator core domain and the generic accounting subdomain are given different priorities.

Strictly speaking, quality in this context means maintainability and adaptability. If a company differentiates itself from its competitors through a product configurator, it needs to be easy to use and adapt. Invoicing, on the other hand, requires other qualities, such as accuracy. A quality problem in invoicing would be unpleasant, but in the case of the product configurator, it turns into a genuine competitive disadvantage because of its importance.

With concrete patterns like core domains, DDD helps concretize the abstract, agile concept of "valuable" software at the level of the software's structure. Accordingly, software can be described as valuable if it achieves high quality in the core domain.