A Brief History of Domain-Driven Design

Welcome to this book on domain-driven design (DDD) using Golang. If you have never heard of DDD before, I hope that by the end of this book, you will have a good understanding of what it is, where it came from, how it can be applied, and how to implement some of the patterns popular among DDD proponents using Golang.

You might be surprised to discover that a large part of the first half of this book will be defining terms and discussing patterns on how to work with others to build systems that represent the real world. At its core, this is what DDD is about. Don’t worry though; there will be plenty of Golang examples, and in Part 2, we will dive deeper into building out DDD-based systems.

In this chapter, we will explore how DDD emerged and gained popularity. I find this context particularly valuable as we delve deeper into the topic as it helps you understand why to use it, not just how.

In this chapter, we will cover the following topics:

The world before DDD
Eric Evans and DDD
Three pillars of DDD
Adoption of DDD
When should you use DDD?

The world before DDD

Before 2003 and the inception of DDD, engineers and architects were thinking about how to organize their software and systems in a way that represented the problem space (domain) they were trying to model. As software became more and more complicated, it became apparent that the closer your system was to the domain, the easier it was to make changes. More importantly, it was easier for other stakeholders to converse with engineers as there was less of a disconnect between the real-world model of the problem space and the system model.

This was the issue that Eric Evans, a software engineer, was facing—the increased complexity of systems and failures in creating and maintaining them. This led him to write the book Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley Professional, in 2003—the first book on the subject of DDD.

“...(The) book Domain-Driven Design was an attempt to capture for people the successful practices that I had seen or used, some of which have been around for a long time and some of which are relatively new, and put together into a coherent set of practices with clear names so that maybe we can have broader success than we have in the past… a great deal of domain-driven design comes straight out of good old-fashioned object-oriented design patterns.” (Evans, in an interview with Software Engineering Radio, 2019, Episode 8: https://youtu.be/7yUONWp-CxM)

What does Evans mean when he refers to object-oriented design (OOD) principles? It used to be a given that everyone would write some object-oriented (OO) code as they began their journey into software development, but that is not necessarily the case anymore. If you are reading this book and Golang is your first programming language, it might be that you have never written traditional OO code.

OO programming (OOP) is a way to write programs that allows us to organize our code around objects rather than functions. We give these objects attributes and methods that define behavior.

OOP is particularly popular for large complex code bases as OOP is much easier to reason about. One of the most popular OOP languages is Java.

If we were building a human resources (HR) system, we might want to model an employee. If we were using Java, we might write this as follows:

public class Employee {
    private String firstName;
    private String lastName;
    public Employee (String firstName, String lastName) {
        this.firstName = firstName;
        this.lastName = lastName;
    }
    public String getFirstName() {
        return this.firstName;
    }
    public String getLastName() {
        return this.lastName;
    }
   
       public String toString() {
        return "Employee(" + this.firstName + "," + this.lastName + ")";
    }
}

As you can see from this basic example, the code is readable, and we can easily model an employee in the system. When the business requires us to print a list of all employees or add the ability to store an employee’s location in their profile, you can hopefully see how our current Employee class forms the basis to add such functionality.

Now that we have learned what OO code looks like, we can review some of the design patterns that are commonly used and that inspired DDD.

So, what are OOD patterns?

Design patterns were first described in 1977 in a book titled A Pattern Language: Towns, Buildings, Construction, by Christopher Alexander, Oxford University Press. This book has nothing to do with software engineering, yet it inspired one of the most influential books on OOP design, called Design Patterns, Elements of Reusable Object-Oriented Software, by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Addison-Wesley Professional. This book was released in 1995 but still features at the top of computer science students’ reading lists in 2022. You may have heard of this book by its colloquial name, the Gang of Four (or GoF), in reference to its four authors.

In the GoF book, 23 design patterns are outlined for what the authors believe lead to scalable, maintainable OO software. Going through each pattern is beyond the scope of this book (the GoF book comprises ~400 pages).

However, if you have read the GoF book, as you proceed to learn more about DDD, it is worth taking a pause and seeing whether you can see where Evans’s inspiration came from. The GoF patterns are split into the following sections, which are equally important when considering DDD:

Creational patterns are patterns concerned with creating objects instead of creating objects directly. This gives more flexibility to the program in deciding which object type to create, given the current context.
Structural patterns are concerned with how you compose objects within your program to achieve certain functionality.
Behavioral patterns are concerned with how objects communicate.

Now that we have learned a little about what inspired DDD, let’s talk about the book that started it all.

Eric Evans and DDD

Evans’s book (sometimes called the Big Blue Book) has become a must-read title for all software engineers and architects. Whenever we talk about DDD, this is the book that started it all. In the book, he gave a common language and a set of principles to design systems that have been refined and clarified over the years by members of an ever-growing community.

The Big Blue Book has sold over 100,000 copies and consistently remains in the top 10 computing books on Amazon. Martin Fowler, a famous thought leader in the software engineering space, describes the book as “an essential read for serious software engineers” (in his martinFowler.com blog, 2020: https://martinfowler.com/bliki/DomainDrivenDesign.html).

However, the book is not without flaws. It has received criticism for being hard to read. In his review, Matt Carroll states: “The book is written in a dialect approaching that of academia. Big words, long sentences, and introduction to concepts that are so abstract that they would be unintelligible without the accompanying examples. In fact, some parts continue to be unintelligible even with the examples” (in his Medium blog, 2016: https://mattcarroll.medium.com/book-review-domain-driven-design-42c96a75a72).

Regardless of the criticism, the book is still as relevant and celebrated as it was years ago when it was published. One reason is that the book outlined three pillars that can be used independently or together to improve complex software projects. In the next section, we will review these pillars.

Three pillars of DDD

In this book, Evans introduced three main concepts (sometimes called pillars) of DDD. These are ubiquitous language, strategic design, and tactical design. We have summarized them in this section, but we go into each in more depth later in this book.

Ubiquitous language

Ubiquitous language is the term we use to describe the process of building a common language we can use when talking about our domain. This language should be spoken by everyone in the team—developers and business folk alike. It unites the team by ensuring there is no ambiguity in communication.

As with real languages, the ubiquitous language should evolve as your team’s understanding of the domain increases. It should never be imposed by domain experts, for it is not a business language. We will discuss how to develop a ubiquitous language in Chapter 2.

Strategic design

Strategic design is a phase of the DDD process in which we map out the business domain and define bounded contexts.

The goal of strategic design is to ensure that you architect your system in a way focused on business outcomes. We do this by first mapping out a domain model, which is an abstract representation of the problem space. If you were working on a shipping system, your domain model might look like this:

Figure 1.1 – A domain model diagram representing a shipping domain

Notice how shipping is at the center of the diagram? This is part of the core domain, and all the surrounding points are there to support shipping.

There is more work to be done here to create bounded contexts, but even at this very early stage of the DDD process, you can start to think about how your system might look.

We will talk about bounded contexts in much more detail in Chapter 2.

Tactical design

Tactical design is where we begin to get into the specifics of how our system will look. In the tactical design phase, we begin talking about entities, aggregates, and value objects, which also happens to be the title of Chapter 3 of this book. We will use these patterns to help us define software boundaries.

Adoption of DDD

DDD has remained popular since its inception, as depicted in the following screenshot, which shows a trend line in a Google Trends graph.

Figure 1.2 – Google Trends graph of searches for DDD

Indeed, it is just as valuable to learn DDD (maybe more so) now as in 2004 (as far back as Google Trends goes).

Although Evans laid the foundation for DDD, it has remained relevant for nearly 2 decades because, in Evans’s own words, “smart and innovative people have shaken things up repeatedly.” These people have taken the fundamentals outlined in a DDD and created new concepts, which have enabled DDD to remain relevant, even though the way we write software has changed quite dramatically.

Some of the books highlighted by Evans are listed here:

Greg Young and his work on Command Query Responsibility Segregation (CQRS): CQRS is a pattern that emerged to capture all application changes as a sequence of events. It allows the segregation of read and write events from the database and can help maximize application performance, scalability, and security. This is particularly popular in large enterprise software.
Domain-Driven Design Quickly: This book was released in 2006 and was (and still is) free; you can read it here: https://www.infoq.com/minibooks/domain-driven-design-quickly/. Evans likes this book as its simple and succinct nature made DDD accessible to everyone.
Vaughn Vernon and his book Implementing Domain-Driven Design: Evans described Vernon’s book as “the most ambitious book since my own.” The community has affectionately called this book the Big Red Book. This book refreshed a lot of the ideas that Evans outlined originally and focused more on how you can implement DDD.

Big companies such as Microsoft, Amazon, and IBM use DDD internally and guide how you can use it too. It is, therefore, still a great time investment to learn about DDD today.

Is DDD always applicable though? Just because big companies use it, it does not necessarily mean it is a good fit for your side project. In the next section, we explore this in more detail.

When should you use DDD?

DDD works best when applied to large, complex systems. A surprising number of the systems Software engineers write today are basic CRUD (short for create, read, update, and delete) applications. Applying DD development to such applications would be overkill and likely make delivery slower and more complicated.

The Big Red Book provides a helpful DDD scorecard. Here is a simplified version of the scorecard:

Is your project . . .	Points	Additional thoughts
Mostly doing simple create, reads, updates, and deletes from the database?	0	Sometimes, evaluating simple can be tricky. If you have lots of business logic between the input and the output, your application might not fit into this category. If all you are doing is validating the input and then passing it through to the database layer, you are in this category.
Does your application have fewer than 30 user stories/business flows?	1	User stories often take this format—as a user, I want an X so that I can Y. Does your system have 30 of these flows? Is it likely to have much more in the future, or are changes mostly minor updates at this point? If it’s fewer than 30, don’t give your system the point here.
Does your application have 40+ user/stories/business flows?	2	We’re starting to enter the territory where we might want to consider DDD. Vaughn correctly highlights that we often do not identify complexity early enough and must pay for that decision later. Consider this your early warning that you are likely building a complex system.
Is the application likely to grow in complexity?	3	Some applications start simple, but there is a clear path to complexity. For example, if you were bootstrapping a startup, you might have something simple for the first few months. But as you attract funding, you know you will have to step up the complexity of the problem you’re solving.
The application will be around for a long time, and the changes you predict you need to make will not be simple.	4	There are very few systems that don’t undergo regular change. Understanding the complexity of the changes necessary is important to deciding whether DDD is right for you. Updating a holiday booking system to understand next year’s public holidays versus making a crypto exchange to support a new protocol are different classes of problems—the latter being worthy of the points for this category.
You don’t understand the domain because it is new, and as far as you are aware, no one has ever built a system like this before.	5	Modeling and defining a domain is DDD’s bread and butter.

Table 1.1 – DDD scorecard

If you score more than 7 points on the table, your application is a great candidate for DDD.

If you have scored less than 7, you may still benefit from some of the principles we will discuss in this book, but it might be that the time investment necessary to implement DDD properly is not worth it.

Committing to following the DDD principles is precisely that—a commitment. It cannot come from engineering; it needs to be a decision involving all project stakeholders. It requires time and effort to get the domain, language, and contexts correct and needs strong involvement from the domain experts. It also requires engineers to think one level higher than software and to think about behavior first.

Summary

In this chapter, we have explored the context in which DDD came to exist, its adoption over time, and an overview of some core concepts. We ended the chapter by highlighting a simple score system that you can use as a reference when discussing DDD adoption with your team.

You should now understand the context of how DDD emerged and have an idea of when it might be appropriate to use it.

In the next chapter. we will dig deeper into some of the core concepts of DDD as we discuss ubiquitous language, bounded context, domains, and subdomains.