Book Image

Domain-Driven Design with Golang

By : Matthew Boyle
5 (1)
Book Image

Domain-Driven Design with Golang

5 (1)
By: Matthew Boyle

Overview of this book

Domain-driven design (DDD) is one of the most sought-after skills in the industry. This book provides you with step-by-step explanations of essential concepts and practical examples that will see you introducing DDD in your Go projects in no time. Domain-Driven Design with Golang starts by helping you gain a basic understanding of DDD, and then covers all the important patterns, such as bounded context, ubiquitous language, and aggregates. The latter half of the book deals with the real-world implementation of DDD patterns and teaches you how to build two systems while applying DDD principles, which will be a valuable addition to your portfolio. Finally, you’ll find out how to build a microservice, along with learning how DDD-based microservices can be part of a greater distributed system. Although the focus of this book is Golang, by the end of this book you’ll be able to confidently use DDD patterns outside of Go and apply them to other languages and even distributed systems.
Table of Contents (13 chapters)
1
Part 1: Introduction to Domain-Driven Design
6
Part 2: Real -World Domain-Driven Design with Golang

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

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.