Normally, when I study DDD, I mostly view it as a developer who try to align oneself with the business domain expert and focus on concepts like ubiquitous language, bounded-context, model discovery, and such.
However, I've come across a talk session that elaborate on designing problems and debriefing project's requirement with DDD and how it change the approach we take on problems. I find it interesting and would like to share the idea here.
If our domain is a hospital and we look at it without domain knowledge, we might assume there's only one user, the patient.
However, if we talk to a domain expert, we'll find that as a user interact with different parts of the system, their status from a business unit perspective changes entirely.
For example:
- when a user goes to the reception desk, they are a Customer.
- After registering and waiting for their doctor's appointment, they become a Patient.
- Once they've been treated and are at the payment counter, they become a Debtor.
- After paying and waiting for their prescription, they might become a Prescription Recipient.
As you can see, when we apply domain knowledge, we can clearly identify four separate subsystems:
1) Customer is a CRM (Customer Relationship Management) system.
2) Patient is the medical records system (which will be our core domain).
3) Debtor is part of the finance system.
4) Prescription Recipient uses the pharmacy inventory system.
If we don't break down these subsystems and instead view them as a single "hospital system," our approach to designing a solution will be completely different. Storing patient entities would result in bloated tables that lack specific meaning.
Additionally, the speaker's point about using strategic design to divide problems into domain and subdomain was excellent. For example, if our domain is a hospital, we could reclassify the domains as follows:
Core Domain: The core business, such as medical records.
Generic Subdomains: Things that stay the same for any business, like CRM or finance.
Supporting Subdomains: Things that are important, but not the most critical, and are needed to support the core, such as the pharmacy inventory system.
Breaking down problems this way allows us to apply different solutions to each part. For instance, if we have a staff shortage, we can categorize the problems this way so our team can focus on what's truly important.
For the core domain, we can have internal staff manage it to retain domain knowledge and dedicate maximum resources to maintain our competitiveness, since this is our core business.
For generic subdomains, we should follow the principle of 'buy before build.' If something is generic, there should already be products available. This way, we don't have to waste our own resources on a domain we might not be proficient in. We can leverage a product from someone who specializes in that domain instead, or hire a vendor for project management.
For supporting subdomains, we could assign two team members and hire a trusted partner under a T&M (time and materials) contract.
If we view the entire problem as a single entity, it's unlikely that we would come up with these kinds of solutions. But once we separate them, the requirements for each part become much clearer, and we can appropriately allocate resources—including people, time, and budget—to each specific problem.
From my experience as a developer who had worked with both project-based and product-based company, I find there are many problems that can be solved much more easily, and sometimes without any code if we really understand the business need.
The original talk in Thai by Mr.Twin was recorded at this link.
Top comments (0)