Welcome to this book ondomain-driven design (DDD) usingGolang. 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 proponentsusing 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 inPart 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 understandwhy to use it, not justhow.

In this chapter, we will cover thefollowing topics:

• The worldbefore DDD
• Eric Evansand DDD
• Three pillarsof DDD
• Adoptionof DDD
• When should youuse DDD?

Before 2003 and the inceptionof 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 thesystem 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 bookDomain-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 withSoftware Engineering Radio,2019,Episode8:https://youtu.be/7yUONWp-CxM)

What does Evans mean when he refers toobject-oriented design (OOD) principles? It used to be a given that everyone would write someobject-oriented (OO) code as they began their journey into software development, but that is not necessarilythe 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 themost popular OOP languages isJava.

If we werebuilding ahuman resources (HR) system, we might want to model an employee. If we were using Java, we might write thisas 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 basicexample, the code is readable, and we can easily model an employee in the system. When the business requires us toprint a list of all employees oradd the ability to store an employee’s location in their profile, you can hopefully see how our currentEmployee 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 thatinspired DDD.

So, what are OOD patterns?

Design patterns were first described in 1977 in a book titledA Pattern Language: Towns, Buildings, Construction, byChristopher 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, calledDesign Patterns, Elements of Reusable Object-Oriented Software, byErich Gamma,Richard Helm,Ralph Johnson, andJohn Vlissides,Addison-Wesley Professional. This book was released in 1995 but still features at the top of computerscience students’ reading lists in 2022. You may have heard of this book by its colloquial name, theGang of Four (orGoF), 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 patternsconcerned with creating objects instead of creating objects directly. This gives more flexibility to the program in deciding which object type to create, given thecurrent context.
• Structural patterns are concernedwith how you compose objects within your program to achievecertain functionality.
• Behavioral patterns are concerned with howobjects communicate.

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

Evans’s book (sometimes called theBig 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.

TheBig 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 hismartinFowler.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 hisMedium 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 reviewthese pillars.

In this book, Evans introduced three main concepts (sometimes called pillars) of DDD. These areubiquitous language,strategic design, andtactical 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 weuse 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 ambiguityin communication.

As withreal 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 inChapter 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 adomain model, which is an abstract representation of the problem space. If you were working on a shipping system, your domain model might looklike 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 inChapter 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 aboutentities,aggregates, andvalue objects, which also happens to be the title ofChapter 3 of this book. We will use these patterns to help us definesoftware boundaries.

DDD has remainedpopular since its inception, as depicted in the following screenshot, which shows a trend line in aGoogleTrends 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 asGoogleTrends 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 changedquite dramatically.

Some of the books highlighted by Evans arelisted here:

• Greg Young and his work onCommand 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 accessibleto everyone.
• Vaughn Vernon and his bookImplementing Domain-Driven Design: Evans described Vernon’s book as “the most ambitious book since my own.” The community has affectionately called this book theBig Red Book. This book refreshed a lot of the ideas that Evans outlined originally and focused more onhow you can implement DDD.

Big companies such as Microsoft, Amazon, and IBM use DDD internallyand 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 inmore detail.

DDD works best when applied to large, complex systems. A surprising number of the systems Software engineers write today are basicCRUD (short forcreate, read, update, anddelete) applications. Applying DD development to such applicationswould be overkill and likely make delivery slower andmore complicated.

TheBig Red Bookprovides a helpfulDDD scorecard. Here is a simplified version ofthe scorecard:

Table 1.1 – DDD scorecard

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

If you have scored less than7, 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 DDDproperly is notworth 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. 

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 withyour 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.

For more information, please refer to thefollowing resources:

• Design a DDD-oriented microservice by Microsoft (2022); availableathttps://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/ddd-oriented-microservice
• Find Your Business Domains to Start Refactoring Monolithic Applications byAmazon Web Services (AWS) (2022); availableathttps://aws.amazon.com/blogs/mt/find-your-business-domains-to-start-refactoring-monolithic-applications/
• Apply Domain-Driven Design to microservices architecture by IBM; available athttps://www.ibm.com/garage/method/practices/code/domain-driven-design/