Everything is broken down:
Books -> Chapters
Worlds -> Countries
Software -> Services
5 virtues of modularity
- Comprehensibility / Cognitive Load
- Parallel evolution / Team Autonomy
- Fine-grained, ROI-aligned investments
- Granular Customisability — do things differently in different modules
- Containment — Isolated failures
How do these apply in the real world:
- I can tell you stuff about Switzerland independent of any other country
The illusion of Boundaries (overemphasized a lot) — the world does not work that way (or even software)
4 languages in Switzerland
West of Switzerland speaks French
-> Understanding language better is key to understand the boundaries better (language carries the influence)
but… Language is confusing
Words do not convey the full meaning
(funny story about tomatoes being classified as vegetable BY LAW in order to be able to collect taxes XD)
To create and maintain good boundaries, DDD practitioners need to learn the domain model of language!!!
Language is often not given enough attention.
You can’t design the optimal bounded contexts if you don’t understand your domain model! — understanding the domain comes first
Generic / Supporting / Core contexts — this is confusing (decide using Model complexity / business differentiation)
High complexity, high business differentiation = core context — but this can change over time!
There are no generic domains? — eg. Slack Generic -> Core, Slack started as an internal chat system it’s now the core domain worth $13bn.
(there is a lot of potential in many generic subdomains)
The market (wants great customer experience)
Software Architecture (a model of the domain)
A book reference: “Team Topologies” — compares team collaboration variants between different types of bounded contexts, and how these evolve
Coupling is based on what's changing in the business not based on the software concepts — even though your services might be
nicely decoupled for the first few months, new business requirements can entangle them. (he proposes different solutions here also, the bottom line is
that the organization needs to be fluid and be willing to reorganize in these cases)
Allow people to define their own teams.
Sometimes technology increases complexity.
More books: Dynamic Reteaming, Domain Driven Design (blue book)
A lot of DDD experts rely on intuition to design bounded contexts … (it just felt right — intuitive, but this is really hard to teach)
Bubble Context / Autonomous Bubble Context
Bounded contexts are like lemmings — they have specific roles and responsibilities (Eric Evans)
There are different types / patterns of contexts eg. octopus enforcer context, gateway interchange context, domain mapper context, ghost context (Mathias)
“Brain” context — anti-pattern (eg. rule engines)
Dissecting bounded contexts:
- Business component
- Linguistics component
- Socio-technical component
- DNA (stuff we don’t understand yet
+ outside influences
Book reference: Living Documentation
Predictions and opportunities:
Ubiquitous language as code
Living documentation for domain language
Capture properties of services as system metadata (diagrams don’t capture these)
Developer to domain expert transformation (this one is inevitable and will continue)
There are still immense opportunities in DDD innovation
Context mapping is really complex and difficult, especially since strategic patterns have socio-technical implications (dependencies = politics)
A very good and hilarious keynote, vas hard to keep notes because of so many goodies, I suggest you see the recording when it comes out.
Big kudos to Nick Tune for it.