Hello! Welcome to your course on Domain-Driven Design. I'm excited to guide you through this journey. Given your extensive background in software engineering, you've likely experienced firsthand how software systems can grow in complexity over time, sometimes to the point where they become brittle and difficult to change. This course is designed to equip you with a powerful set of principles and patterns to manage that complexity at its source: the business domain itself.
In this first lesson, we will establish the foundational "why" and "what" of Domain-Driven Design (DDD). We'll define its core concepts, explore its primary goals, and understand the problems it aims to solve. This will lay the groundwork for our entire course and the B2B SaaS billing system project we will be building together.
The Challenge of Long-Term Software Development
Before we dive into definitions, let's start with a problem you've almost certainly encountered. We often begin projects with clean code and high velocity, especially with modern tools like Go and microservice architectures. However, as features are added and requirements evolve, complexity can creep in, slowing development and increasing the risk of bugs.
The article "Introduction to DDD Lite" by Robert Laszczak, a Go developer, captures this experience well. It addresses the common sentiment in the Go community that techniques like DDD are "doing Java in Golang," and makes a compelling case for why that perspective is short-sighted.
Introduction to DDD Lite: When microservices in Go are not ...
This reading sets the stage by arguing that simply using a "simple" language like Go or a microservices architecture doesn't automatically prevent software from becoming a legacy monster. It frames DDD as a crucial strategy for long-term project health.
Please read the first part of the article, from the beginning down to the section titled "What is DDD (Domain-Driven Design)". As you read, focus on the author's argument about the long-term costs of taking shortcuts and how even microservices are not a silver bullet if not designed correctly.
The key insight here is that to build software that is resilient and adaptable over the long term, we need to focus on more than just technology choices. We need a way to structure our code that is deeply connected to the business problem it's solving. This is the central promise of DDD.
What is Domain-Driven Design?
At its heart, Domain-Driven Design is an approach to software development for complex problem domains. It's a philosophy that puts the business domain—the subject area and business logic—at the absolute center of the project. Instead of letting technical details or database schemas dictate the software's design, DDD insists that the software's structure and language should mirror the business itself.
Khalil Stemmler's introductory article provides a wonderfully clear summary of the primary goals of DDD.
An Introduction to Domain-Driven Design (DDD) | Khalil Stemmler
This article clearly outlines the core objectives of DDD.
Please read the section titled "About Domain-Driven Design". Pay close attention to the three main goals the author outlines.
As you just read, the goals of DDD are to:
- Discover the domain model through collaboration with domain experts.
- Embed the domain terminology into the code, creating a rich model.
- Protect that domain model from other technical concerns.
These three goals form a continuous, reinforcing cycle.
Let's break down the key concepts that make this possible.
The Core Concepts of DDD
1. The Domain and Domain Experts
The "domain" is simply the world your software lives in. For our project, it's "B2B SaaS subscription billing." This includes concepts like customers, subscriptions, invoices, payments, and the rules that govern how they interact.
A Domain Expert is anyone who has deep knowledge of this domain. They are not necessarily technical. They could be product managers, accountants, or sales staff. In DDD, developers don't work in isolation; they work in close partnership with domain experts to understand the nuances of the business.
This video from the ProgrammingPercy channel provides a simple but effective illustration of this crucial collaboration.
How To Implement Domain-Driven Design (DDD) in Go
This video explains the fundamental interaction between engineers and domain experts.
Watch the segment from this introduction to DDD, where the narrator defines the domain and the role of Subject Matter Experts (SMEs). Then, continue with the section from the tavern analogy, which illustrates how this collaboration leads to a shared understanding.
2. The Ubiquitous Language
The output of the collaboration between developers and domain experts is the Ubiquitous Language. This is a single, unambiguous language that is shared by everyone on the project—developers, experts, and stakeholders. If the business calls a client a "Customer," then the code should have a Customer type, not a User or Client.
This eliminates ambiguity and translation errors. The code becomes a direct expression of the business model, making it more understandable, maintainable, and verifiable by the people who actually understand the business rules.
3. Strategic and Tactical Design
DDD is not a single pattern but a collection of them, broadly divided into two categories:
- Strategic Design: This is the high-level, "big picture" part of DDD. It's focused on understanding the domain landscape, breaking it down into logical parts called Subdomains, and defining clear boundaries between them, known as Bounded Contexts. This is where you make architectural decisions that align with business structure. Your interest in system design and how businesses operate will be particularly relevant here.
- Tactical Design: This is the low-level, implementation-focused part. It provides a toolbox of building blocks—like Entities, Value Objects, and Aggregates—for creating a rich, expressive domain model within a Bounded Context. This is where your programming experience comes into play, as you'll translate the model into robust, maintainable Go code.
This video gives a concise overview of this crucial split.
Domain-Driven Design: The Last Explanation You'll Ever Need
This video introduces the two main parts of DDD and reinforces the importance of the Ubiquitous Language.
Watch the section explaining the difference between Strategic and Tactical design. Then, watch the segment on the Ubiquitous Language, which provides a practical example of why agreeing on terminology is so important.
Throughout this course, we will maintain a firm balance between these two aspects, applying strategic principles to our SaaS billing project first, and then using tactical patterns to implement the resulting design in Go.
Conclusion
In this lesson, we've laid the conceptual foundation for our study of Domain-Driven Design. You now have a high-level understanding of what DDD is and, just as importantly, why it is a valuable approach for building complex, long-lasting software systems.
Here are the key takeaways:
- DDD tackles complexity at its root: It's a strategy to manage the inherent complexity of a business domain, not just technical complexity.
- It aligns software with business: The central goal is to create a software model that is a direct reflection of the business domain, using a shared Ubiquitous Language.
- Collaboration is key: DDD requires a close partnership between developers and domain experts to uncover and model the business rules accurately.
- It has two sides: Strategic Design focuses on the big-picture architecture of the system, while Tactical Design provides patterns for implementing the model in code.
In our next lesson, we will move from theory to practice. We will explore the role of the domain expert in more detail and begin the process of defining the Ubiquitous Language for the core of our SaaS billing system: the subscription lifecycle.