O’Reilly Learning Course:
Domain Driven Design – Software Architecture
Andrew Harmel-Law
The Heart of Domain-Driven Design
Complexity in Software Tackling complexity is the heart of software. Complexity is in the problem domain, not in our software. We add our own complexity in solving the problem that may or may not be needed. This additional complexity is on us.
Concepts of that are Core to Successful Domain Driven Design
Ubiquitous Language
Domain Experts are developers who can’t code and we are developers who don’t know the domain.
Translation fractures the language between the developer and the business. It’s a mental overhead and things are always lost in translation. If we (the engineering team) and the business have the same understanding and use the same terminology there is no overhead to communication concepts. There is no opportunity to lose meaning in translation. What the point of using two different terms to mean the same thing? Isn’t this idea much like copy and pasting code? They might be the same to start with, but they always diverge over time?
Why are accounts in the banking domain opened and not created?
Respect the domain experts, the domain might seem simple, but once you start talking to the domain experts, it’s not. Domain experts have the solution to one of the hardest problems in Software Development and that’s they names for all the concepts.
Domain experts have a term that succinctly communicates a complex idea?
Are they correcting your word usage?
If so, these are the hints of a complex ideas and the naming to got along with it.
Hands-On Modelers
Developer assumptions get shipped to production and sometimes these assumptions are wrong.
In a typical organization the business domain is documented by a Business Analysis, which records what they think the developers will need. This document is then handed to the Developers. The Developers are reading the Cliff Notes version of the domain problem. This may or may not be the details the developers need to complete their work. Getting the Developers as close to the source of information gives the highest chance of getting the software right.
Engineers working on the model must understand the change they are making and how they are improving the model. If they don’t understand this then they are weakening the model.
Tests verify the facts of your Ubiquitous Language are still true.
Procedural and Data-Centric don’t work for DDD.
Breakthroughs (fine tuning the Ubiquitous Language)
Focus on breakpoints on the Ubiquitous Language. ARea’s of the domain/model that break down and don’t meet the needs of the problem domain.
Tests don’t do this because most of the time you are testing the positive of the assumptions.
Multiple Models
"Bounded Contexts"
A bounded context is an area of the problem domain that had natural or logic borders from other idea’s in a system.
DRY (Don’t Repeat Yourself) doesn’t apply across Bounded Context boundaries. If you do, you are coupling these two Bounded Contexts. The fact that they are two bounded context means they are two different spaces and shouldn’t have overlap. Sharing algothrims is coupling.
If there are truly algorithms that span Bounded Contexts, they should be cross-cutting concerns. For example, working in the financial industry and using financial calculations in multiple Bounded Context is an example of Cross-Cutting concerns.
DRY isn’t about code, it’s not about removing code duplication, but removing duplication of knowledge.
Nested Bounded Contexts aren’t a thing.