Hello! In our last lesson, we introduced the core concepts of Domain-Driven Design, establishing that its primary goal is to manage complexity by aligning software directly with the business domain. We briefly defined the roles of domain experts and the Ubiquitous Language.
Today, we're going to dive much deeper into the first and most critical relationship in any DDD project: the partnership between developers and domain experts. This lesson will move beyond a simple definition to explain why this collaboration is indispensable for building software that solves the right problems, and how to engage in this process effectively. You'll see that this is not a passive Q&A session, but an active, collaborative process of discovery.
The Value of Interaction
In your 15 years as a software engineer, you've likely seen projects where developers were handed a thick requirements document and expected to build software in isolation. This "waterfall" approach often leads to misunderstandings, rework, and a final product that doesn't quite meet the business's actual needs.
DDD fundamentally rejects this model. It argues that immense value is created in the continuous dialogue between the technical team and the business experts.
Domain-Driven Design Made Me Realize Something About AI Tools
The YouTube channel ArjanCodes offers a great perspective on this. This video explains why the idea of separating domain knowledge from development is flawed.
Please watch the segment from the beginning, where the narrator critiques the "throw it over the wall" approach. Then, watch the part about cultivating a common language, which emphasizes that both developers and experts learn from each other in this process.
As you saw, you simply can't write effective software for a domain you don't understand. The interaction isn't a formality; it's a core part of the development process itself. This collaborative discovery is often called "Knowledge Crunching."
The Art of Knowledge Crunching
Knowledge crunching is the art of distilling relevant information from the vast ocean of business operations into a useful software model. It's an active, ongoing process of learning, questioning, and refining.
[PDF] The Anatomy Of Domain-Driven Design (2019) - Scott Millett
This guide by Scott Millett provides excellent, practical advice on engaging with domain experts.
First, read the section "Employ Knowledge Crunching Techniques". Focus on the definition of knowledge crunching and the tips for engaging experts. Next, read the section "Ask powerful questions". Notice how these questions go beyond simple features to probe the underlying business strategy and value—something that aligns with your interest in economics and business operations.
The key is to move beyond a passive list of requirements. Instead of asking "What should this button do?", we ask "What is the business trying to achieve here?". By focusing on concrete scenarios and asking powerful questions, we tap into the expert's deep, often tacit, knowledge.
Uncovering Hidden Complexity: A Case Study
Business concepts that seem simple on the surface often hide a surprising amount of complexity. This is where domain experts are most valuable—they navigate this complexity every day. A developer's job is to help them articulate the rules and nuances they might not even realize are rules.
The following video provides a brilliant, step-by-step demonstration of this process. The presenter simulates a conversation with a domain expert for a car registration shop, showing how a seemingly simple domain is full of intricate rules.
Want to Start with DDD? Try Ubiquitous Language First!
In this video from the channel Zoran on C#, you'll see knowledge crunching in action.
Watch the extended example starting from the conversation with the domain expert. Pay close attention to how the initial term "car" evolves into "vehicle," and how the simple concept of "allowed persons count" unravels into a complex set of rules involving different types of seats, seat belts, and even regional legislation. This is the essence of discovering the domain.
This simulation perfectly illustrates that the most important domain knowledge is often hidden. Without this deep, collaborative questioning, the team would likely have built a simplistic model that fails to handle the real-world complexity of the business.
A Two-Way Street: The Developer's Role
This process is not a one-way transfer of information. As an experienced engineer, your analytical skills are a critical part of the equation. You are not a passive scribe; you are a co-creator of the model. You help structure the conversation, identify inconsistencies, and ensure the resulting model is technically sound.
Before Code Steps in Domain-Driven Design (DDD) Methodology
This article highlights the pre-coding steps in DDD and reinforces the collaborative nature of model validation.
First, read the section "Understand the Business Domain" and note the key questions it suggests asking. Then, jump to the section "Model Validation with Domain Experts". The dialogue between the developer and the domain expert about the Order and Payment concepts is a perfect example of a developer using their technical knowledge to challenge and refine the model, leading to a better design.
The Order and Payment example is crucial. The developer's initial impulse is to put a PaymentStatus on the Order, which is a common pattern. However, the domain expert clarifies that they are separate processes. The developer's role is to hear that, and use their knowledge of system design to propose a better structure—in this case, two separate but linked concepts (which we will later call Aggregates). This is a partnership.
The ultimate goal of this intense collaboration is to build a shared understanding and a common vocabulary—the Ubiquitous Language.
This language, born from collaboration, becomes the foundation for the entire project, ensuring that the software you build is a true reflection of the business it serves.
Conclusion
In this lesson, we've explored the vital importance of the developer-domain expert partnership. This relationship is the engine of Domain-Driven Design.
Key takeaways from today's session:
- Collaboration over Documentation: DDD replaces the "throw it over the wall" mentality with a continuous, collaborative dialogue. The interaction itself creates value.
- Knowledge Crunching is an Active Process: It involves asking powerful questions, exploring concrete scenarios, and actively distilling information to uncover the deep knowledge that experts possess.
- It's a Partnership: Developers bring critical analytical skills and technical expertise to the table. They help structure the domain expert's knowledge into a coherent and implementable model.
- The Goal is a Shared Language: The result of this collaboration is the Ubiquitous Language—a single, unambiguous vocabulary used by everyone, which bridges the gap between business and code.
We've now established the why and how of working with domain experts. In our next lesson, we will put this directly into practice. We'll take a set of business requirements for our B2B SaaS billing project and begin the process of knowledge crunching to extract the initial Ubiquitous Language for the subscription lifecycle.