Buzzword-free Bounded Contexts

My recent attempt at explaining Bounded Contexts at @DDDBE, was criticised for being too heavy on terminology. Rinse, adjust, repeat.

Published on 13 February 2014 by @mathiasverraes

Context is everywhere. The human brain interprets context immediately, without effort. Try this:

Note how easy it was for you to derive context. For machines, this is hard, which is one reason we feed them models with unambiguous names.

The difference is often even a lot subtler.

In each of these departments, people know the context perfectly well. They don’t bother finding a different name, because even though it’s all called product, there’s never any misunderstanding.

A Model within a Context

Separate into Bounded Contexts

And then the software developers come along, and we put all these totally different things that are all called product, in the same database table and model. We’re supposed to be the smart guys, but we’ve been fooled by the fact that they share the same name. We’ve totally missed the context. We end up with a huge model, that tries to be all these things at once, for every department, despite the fact that these departments are quite independent in real life anyway.

Now imagine that instead of one team, building one application and one model, we have three teams, in three different companies, building three separate systems: Salesify, SaasInventory, and SpeedyShip. It’s up to the users to integrate them. Nobody is calling the other teams going “Hey, we should all share one database!”. That’s a recipe for disaster. They use different infrastructure, different storage, different models. What you would do, is agree on a narrow, strictly defined way to integrate the systems. You could use messaging, an API, import scripts, or dumping files on an FTP.

Whether the three teams will easily reach agreement on those integration contracts, is a whole different discussion. But apart from that, it’s great not to share your database, or any other infrastructure. It gives you freedom. There is no complication from trying to put all the things in one model.

So why do we make it so hard on ourselves when we are just one team? We can borrow the benefits of having multiple teams (clarity, clean separation), without the downside (communication overhead). That’s essentially what Bounded Contexts are about:

Read more

Follow @mathiasverraes on Twitter.



Upcoming

2018
Topic Event Type Location Date
Advanced Domain-Driven Design DDD Europe workshop Brussels, Paris 2018
Design Heuristics DDD eXchange keynote London April 2018
DDD for Messaging Architectures ExploreDDD workshop Denver Sep 2018
Design Heuristics Kandddinsky talk Berlin Oct 2018
Tactical DDD Kandddinsky workshop Berlin Oct 2018
Past agenda entries...

Blog

2016

2015

2014

2013

2012

2011

Creative Commons License This work by Mathias Verraes is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 License.