E-Book, Englisch, 204 Seiten
Boyle Domain-Driven Design with Golang
1. Auflage 2024
ISBN: 978-1-80461-926-1
Verlag: De Gruyter
Format: EPUB
Kopierschutz: 0 - No protection
Use Golang to create simple, maintainable systems to solve complex business problems
E-Book, Englisch, 204 Seiten
ISBN: 978-1-80461-926-1
Verlag: De Gruyter
Format: EPUB
Kopierschutz: 0 - No protection
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.
Autoren/Hrsg.
Fachgebiete
Weitere Infos & Material
Table of Contents - A brief history of Domain Driven Design
- Understanding Domains, Ubiquitous Language, and Bounded Contexts
- Aggregates, Entities & Value Objects
- Factories, Repositories & Services
- Applying Domain Driven Design to a monolithic application
- Building a microservice using domain driven design
- Domain Driven Design for distributed systems
- TDD, BDD and DDD
1
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 , 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 to use it, not just .
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 , , in 2003—the first book on the subject of DDD.
“...” (Evans, in an interview with , , : 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 or , 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 , by , . This book has nothing to do with software engineering, yet it inspired one of the most influential books on OOP design, called , by , , , and , . 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 ) 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 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 “” (in his blog, : 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: “” (in his blog, : 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...




