Introduction to Domain-Driven Design pt. 2: Understanding Complex Domains

Photo by Michal Matlon on Unsplash

Domain-Driven Design (DDD) is a software development approach that focuses on understanding and modeling the problem domain. In his book “Domain-Driven Design: Tackling Complexity in the Heart of Software,” Eric Evans argues that a good model of the domain is essential for building high-quality software that meets the needs of users and stakeholders.

In the first part of this series, we discussed the fundamentals and key concepts of DDD. In this article, we will go a little deeper into what a model is and how to think about it, using the blue book as the main source of knowledge.

The model

The first chapter of the book provides an overview of DDD and explains why it is important to focus on the domain when developing software. According to Evans, many software projects fail because developers do not have a clear understanding of the problem they are trying to solve. He argues that to build successful software, developers must have a deep understanding of the domain and be able to communicate effectively with domain experts.

One of the key concepts in DDD is the model, which is a representation of the problem domain. The model is not just a set of classes and objects, but a shared understanding of the domain that can be used to guide software design and implementation. Evans stresses the importance of creating a model that accurately reflects the domain and is understood by all stakeholders.

In DDD, three basic uses determine the choice of a model:

1. The model and the heart of the design shape each other: the link between the model and the implementation helps during maintenance and continuous development because the code can be interpreted via model understanding;
2. The model is the backbone of a language used by all team members: with that assumption, developers can communicate with domain experts and with other developers in a language that is close to the domain;
3. The model is distilled knowledge: a model allows developers and domain experts to collaborate effectively as they wrestle information in this form.

A domain model is not a particular diagram; it is the idea the the diagram is intended to convey.

The famous pipe. How people reproached me for it! And yet, could you stuff my pipe? No, it’s just a representation, is it not? So if I had written on my picture “This is a pipe”, I’d have been lying!

The scope of knowledge encapsulated in a model surpasses the mere identification of entities through the “find the nouns” approach. The activities and rules that govern a business are just as essential to the domain as the entities themselves, and a domain will typically contain multiple categories of concepts. Developers simultaneously refactor the implementation of an application to align it with model changes, allowing the application to incorporate and leverage the knowledge encapsulated in the model.

Ingredients of Effective Modeling

Here are the ingredients that lead to success while modeling:

1. Binding the model and the implementation;
2. Cultivating a language based on the model;
3. Developing a knowledge-rich model;
4. Distilling the model;
5. Brainstorming and experimenting.

Ubiquitous Language

Another important concept in DDD is the ubiquitous language, which is a language that is shared by all stakeholders in the domain. The ubiquitous language includes domain-specific terminology and concepts that are used to describe the problem domain. By using a ubiquitous language, developers and domain experts can communicate effectively and avoid misunderstandings.

The Ubiquitous Language will be detailed in the next posts of this series.

A model for a barbershop scheduling application

Let’s see an example of modeling for a barbershop scheduling application. We can imagine that our stakeholders are managers of barbershops, and we can do a bit of practice in modeling by defining the model of an application used by clients of the barbershops to schedule appointments.

A scheduling application for barbershops might have the following domain model:

• Barber: An individual who cuts hair for clients.
• Client: An individual who receives haircuts from barbers.
• Appointment: A scheduled time slot during which a client receives a haircut from a barber.
• Service: A specific type of haircut that a barber can provide, which has a duration and a price.
• Availability: A specific period of time during which a barber is available to provide haircuts.

However, after analyzing this model, it easily comes out that something is missing: the service should be an archetype and a single barber should be able to either provide it or not. So we will introduce a new concept:

• Service instance: A specific service provided by a single barber.

The model that comes out (over-simplified) is the following:

In addition to these core concepts, the domain model might include the following domain services:

• Booking: A service that allows clients to schedule appointments with barbers.
• Availability Checker: A service that allows clients to check the availability of barbers for specific time slots.
• Payment: A service that allows clients to pay for appointments and services.

The ubiquitous language for this domain might include terms such as “haircut,” “appointment,” “barber,” and “client.” The model might be organized into bounded contexts based on different areas of functionality, such as booking appointments, managing barbers and services, and processing payments.

Overall, the domain model provides a shared understanding of the key concepts and relationships in the scheduling application for barbershops and guides the development of the application’s design and implementation.

It is important to notice that the process of modeling is an iterative process and can take a lot of time brainstorming and experimenting to find the right model that best fits our domain.

Conclusions

In summary, a model is a representation of the problem domain that captures the essential aspects of the domain and can be used to guide software design and implementation. The model includes entities, value objects, domain services, and bounded contexts, and is described using a ubiquitous language that is understood by all stakeholders. These topics will be discussed in the other articles of this series that will come (hopefully) soon.