Learn the vocabulary of modeling software directly around a business domain's own language and structure.
0 / 5 completed
1 / 5
At standup, a dev mentions modeling the software's structure and vocabulary directly around the business domain's own concepts and language, built through close, ongoing collaboration between developers and domain experts around a shared vocabulary. What is this approach called?
Domain-driven design is exactly this: it models a system's structure and vocabulary directly around the business domain's own concepts, built through close, ongoing collaboration between developers and domain experts around a shared ubiquitous language, so the code's terms match the business's terms exactly. A hash collision is an unrelated hash-table concept about two keys sharing a bucket. This model-the-domain-directly approach is exactly why domain-driven design reduces the translation gap between what the business means and what the code expresses.
2 / 5
During a design review, the team adopts domain-driven design for a claims-processing system, specifically because using the exact same 'claim,' 'adjuster,' and 'settlement' vocabulary in both code and business conversations avoids ambiguity in what each term means. Which capability does this provide?
Domain-driven design here provides a shared vocabulary that eliminates translation ambiguity, since the code and the business use the exact same domain terms, so a term like 'claim' never means one thing in a conversation with a domain expert and something subtly different in the code. Letting developers choose their own technical terms for domain concepts independently reintroduces exactly the ambiguity domain-driven design is meant to remove. This shared-vocabulary behavior is exactly why domain-driven design is favored for complex business domains where miscommunication is costly.
3 / 5
In a code review, a dev notices a claims-processing codebase calls the core business concept a 'Record' internally, while every domain expert and business document refers to the exact same concept as a 'Claim,' with no shared vocabulary connecting the two. What does this represent?
This is a missed domain-driven-design opportunity, since adopting the business's own term for the concept in the code would eliminate the ambiguity between what 'Record' means in code and what 'Claim' means to the business. A cache eviction policy is an unrelated concept about discarded cache entries. This mismatched-vocabulary pattern is exactly the kind of miscommunication risk a reviewer flags once developers and domain experts need to discuss the same concept accurately.
4 / 5
An incident report shows a costly requirements misunderstanding shipped to production, because the code's internal term for a concept didn't match the business's own vocabulary, and a developer implemented what a 'Record' meant to them instead of what a 'Claim' actually meant to the business. What practice would prevent this?
Adopting domain-driven design has the code adopt the business's own term and meaning directly instead of letting a developer's independently chosen term drift from what the business actually means. Continuing to let the code use its own internally chosen vocabulary regardless of how often it drifts from what the business actually means is exactly what caused the misunderstanding described in this incident. This shared-vocabulary discipline is the standard fix once a domain's terminology is confirmed to carry real business meaning.
5 / 5
During a PR review, a teammate asks why the team invests in domain-driven design instead of simply having a business analyst write requirements documents that developers translate into whatever code vocabulary they prefer. What is the reasoning?
Domain-driven design keeps the business's own vocabulary embedded directly in the code through ongoing collaboration, so a term's meaning can never silently drift during translation, while translating a requirements document into a developer's preferred vocabulary reintroduces exactly the ambiguity that a shared vocabulary is meant to prevent. This is exactly why domain-driven design is favored for complex business domains, while a one-time translated requirements document remains prone to drift over time.