Dissecting Bounded Contexts (DDD EU 2020 talk summary)

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)

Socio-technical Architecture:

Engineering teams

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.