Thread by @mathiasverraes

I’m having lots of conversations with @rebeccawb about Bounded Contexts in Domain-Driven Design. This is a small snapshot of some of the tensions involved in picking good boundaries.
🧵⬇️ (1/15)

Some context:

A Bounded Context is an “understandability boundary”, a boundary around a model and its language. You can understand the model and the language in isolation, without having to understand other Bounded Contexts. (2/15)

An Interface is the set of contracts or message types or APIs between Bounded Contexts. They translate from one model and language to another. (3/15)

A Bounded Context or Interface is evolvable if we are able to make frequent, safe, and cheap changes to it.

When designing evolvable Bounded Contexts (BCs), there are fundamental tensions that affect our design. (4/15)

[1] A BC is evolvable on the inside if it is small and understandable and has a small stable Interface.

[2] A system of BCs is evolvable (adding, removing, reconfiguring BCs) if the Interfaces are small and understandable. (5/15)

[3] The tension between [1] and [2] is that choosing many small BCs implies having larger Interfaces, but choosing many small Interfaces implies having larger BCs. (6/15)

[4] The Interfaces themselves are more evolvable if they integrate fewer BCs, and less evolvable if they integrate more BCs.

[5] The consequence of [2] and [4] is that a small evolvable Interface makes adding BCs easier, but becomes less evolvable in the process. (7/15)

[6] It’s easier for a BC to offer a single generic shared Interface, than many specialised Interfaces for each consumer. Having many specialised Interfaces is harder to maintain when the BC changes. (8/15)

[7] It’s easier for a BC to consume a specialised Interface, adapted to that BC. Generic interfaces are bloated because they support other consumers, and therefore require more integration work. (9/15)

[8] Trading off [6] and [7] involves finding a small set of semi-specialised Interfaces, that are shared between some consumers with similar needs. (10/15)

[9] Coordination between teams (which is in fact coordination of understanding, aka sharing models and language) is expensive, which is one of the reasons we have BCs to begin with. (11/15)

[10] Achieving [8] requires more coordination between more teams than either a single generic Interface or individual specialised Interface. (12/15)

There are no solutions or hard rules to make these trade-offs. Instead, you need to use heuristics for making the trade-offs, and heuristics for knowing when to choose different trade-offs than the ones you originally made. (13/15)

Also available as a blog post over at my site verraes.net/2021/04/tensio… (14/15)

(Domain modelling, strategic design, and just generally figuring out problems like these is what my company does. DMs are open if you want us to work with you. )(15/15)