# Domain-Driven Design

> Model software around the language, rules, and boundaries of the problem domain.

- HTML version: https://robbiepalmer.me/ideas/domain-driven-design
- Source: https://www.domainlanguage.com/ddd/

Domain-Driven Design treats the domain model as a product of sustained collaboration between domain
experts and software builders. The model lives in code and language, not in a diagram handed over
before development begins.

Its most useful move is admitting that one universal model is often worse than several explicit
ones. A term can mean different things in different bounded contexts. A context map then describes
how those models meet and where translation belongs.

I care less about reproducing every named tactical pattern than about keeping language honest. If
the team, interface, database, and user all use the same word for different concepts, the design is
already accumulating ambiguity.

## Questions it prompts

* What language do the people doing the work already use?
* Where does the meaning of a term change?
* Which rules belong together and which should stay behind a translation boundary?

## Related ideas

- [Data Mesh](https://robbiepalmer.me/ideas/data-mesh.md): A decentralised approach to analytical data built on domain ownership, data products, a self-serve platform, and federated governance.
- [EventStorming](https://robbiepalmer.me/ideas/eventstorming.md): A collaborative workshop method for discovering how a domain behaves by mapping events and the forces around them.

## Where it appears

- Project: [Intelligent Document Processing](https://robbiepalmer.me/projects/intelligent-document-processing.md)
- Blog post: [The Philosophy of Data Science](https://robbiepalmer.me/blog/2022-03-02-the-philosophy-of-data-science.md)

---

Markdown index of this site: https://robbiepalmer.me/llms.txt