If you have been a programmer for some time, you have probably heard the term Domain-Driven Design (DDD). Blogs, books, conferences – it seems to be everywhere. Everyone who has implemented it in their project, successfully or not, often praises this approach. That is what DDD is: an approach to software design that involves, and strongly relies on, cooperation and communication with people called Domain Experts (DE). In almost every company, there is at least one person who fits this role.
Before we can dive deeper into DDD, we need to focus on the word Domain. I have already used it several times, so let’s start there and clarify what Domain actually means in this context.
Domain
When encountering an unfamiliar word, or a familiar word with multiple meanings, consulting a dictionary is a good start. Looking up “domain” in sources like the Cambridge Dictionary reveals several definitions. For our purposes, the Business English definitions are most relevant:
- a particular interest, activity, or type of knowledge
- a business activity that is controlled by a particular industry or group of people
These definitions guide us toward understanding a company’s core. It essentially boils down to answering two simple questions: what does the company do (its business activity) and how does it do it (its specific knowledge and processes). While the questions seem simple, the answers rarely are. DDD was developed to help manage the complexity that arises when building software around these core business activities and knowledge.
Domain Expert
The Domain Expert (DE) plays a crucial role in the DDD approach. The knowledge and experience of DEs are vital for a company’s success. All the models and business logic you will implement originate from one or more DEs. Your task as a developer or architect is to gather the necessary information from them and translate it into DDD’s building blocks.
Strategic and Tactical Design
DDD is typically divided into two main phases: Strategic Design and Tactical Design.
- Strategic Design focuses on the big picture: understanding the business landscape, identifying different business areas (Domains and Subdomains), defining the boundaries between them (Bounded Contexts), and mapping their relationships (Context Mapping). It helps decide where to focus development efforts.
- Tactical Design deals with refining the models within a single Bounded Context. It provides building blocks like Entities, Value Objects, Aggregates, Repositories, and Domain Events to create rich, expressive domain models.
These phases provide tools to better understand and implement complex systems, often supporting multiple Domains and even more Subdomains. In this tutorial series, we will begin with the Strategic phase, using our example company to explore these high-level concepts first.
But how do you identify the right people to fulfill the DE role?
How To Identify the Domain Expert?
It might be tempting to look for a DE among programmers or project managers. While potentially valid in some specific cases, developers are often experts only in particular technical aspects, not the entire business domain. Similarly, project managers might understand project scope but lack deep insight into the company’s core knowledge and processes. Furthermore, some businesses might not even have an internal IT department.
Consider a law firm as an example. The Domain is law. If you were building software to help judges determine sentences, potential domain concepts might include: accused person, criminal code, sentencing guidelines, prior convictions, and sentence range. The software should calculate a suggested sentence range based on relevant factors like criminal history. Imagine the disastrous consequences if the logic mistakenly applied the penalty for fraud instead of a parking violation.
We have identified some core concepts. Now, who are the Domain Experts? In this “Sentencing Helper” application, experienced lawyers and judges would be ideal DEs. They are experts in the law Domain, possess practical experience, and can validate the implemented logic, providing crucial answers and feedback.
Let’s Define Some Business
Reasoning about concepts is always easier with a concrete example. For this tutorial, we will use an imaginary company that operates in a familiar domain: a specialized bookstore. This company, SHELF, will be a client of a software house called Trinity, where Peter works as a software architect.
Company Description
SHELF is a bookstore specializing in Cookbooks. Like many other bookstores, SHELF employs several people. The enterprise is run by Frank, a man with a great passion for both books and cooking. Peter will speak with him to kickstart the project. This initial phase is also a good opportunity to try to pinpoint potential Domain Experts.
Staff
Here are profiles of the employees at SHELF. These descriptions aim to provide insight into their roles within the company and serve as a narrative background. In a real project, obtaining such detailed information upfront might be unlikely.
Frank (CEO)
Frank believes that high-quality products always find buyers, and this applies equally to cooking. People constantly seek new recipes because eating is fundamental. Having graduated from Cooking School, he has a keen eye for quality cookbooks. Before deciding to stock a book, he orders sample copies from various publishers. Only a select few pass his rigorous evaluation process. Whether accepted for sale or not, samples must be returned to the publisher after a specified period, with deadlines varying between publishers. Frank’s expertise in cooking and book selection makes him a likely DE for product curation.
Katie (Clerk)
Katie is the person who greets customers visiting SHELF. She possesses extensive knowledge about the store’s merchandise, including its location and how to find specific publications with minimal information. Katie also handles incoming deliveries, unboxing them, and ensuring they are placed on the correct shelf. Her deep understanding of inventory and in-store operations suggests she is a DE for that part of the business.
Marlon (Marketing)
Marlon ensures that cooks and aspiring cooks know about SHELF and its current promotions. He employs various marketing tactics, including billboard campaigns, TV commercials, and flyers. His efforts contribute significantly to the store’s sales performance. He utilizes external systems like Google Analytics and Google Ads to maximize reach. Marlon is the obvious DE for marketing strategy, promotions, and customer acquisition channels.
Zoe (Social Media)
Zoe, who likes the title “Social Media Ninja,” manages the company’s presence on Facebook, Instagram, and YouTube. She moderates the “SHELF FANS ONLY” Facebook group, creates engaging content for Instagram, and uses YouTube for video features. Zoe is the DE concerning social media engagement, online community management, and digital content strategy.
Summary
You have been introduced to SHELF, a specialized bookstore business. While seemingly straightforward, their operations involve various complexities, making the Domain non-trivial. In the upcoming posts, we will begin the Strategic Design phase of DDD, analyzing SHELF’s business to identify its core domains and subdomains using the appropriate tools. Stay tuned as we explore the DDD world together.