If you’ve ever heard Eric Evans speak about the big blue book that he authored, you’ll probably know that he regrets that he didn’t put part IV at the beginning. Why? well, not only are the topics covered some of the most important, he also knows that a lot of developers studied the many patterns at the beginning of the book but then stopped before reaching that critical part. If you’re one of those developers who have an interest in DDD (and really, you should) but never got far enough through to study bounded contexts, I’d encourage you to go back and give it the attention it deserves. Bounded Context is arguably the most important concept you could learn from DDD and is incredibly useful even if you’re not doing DDD.
All too often, in the software projects I’ve been lucky(?) enough to be exposed to the application is made up of one huge, inter-connected web of objects, that make it all but impossible to comprehend and even harder to safely change. We know that according to SRP objects should have one reason to change, a single responsibility. But why stop there? Why not apply this idea at the application level too? If we have an e-commerce web site, it’s raison d’etre is to take orders. That’s where it delivers value and justifies its existence so the question is, should it also be responsible for updating the inventory? Should it allow internal users to create and run reports too? And what about administration? Is that related to making a sale? Well, the answer is “it depends” of course but it’s reasonable to argue that these areas are different and might have unique needs. Each of these “contexts” likely have different forces that pull in opposing directions but if we don’t recognise them we often end up creating one of the aforementioned monolithic models that tries to be all things to all people and ends up doing none of what it was intended to do very well. It’s hard enough that the problem domain that we work in consists of what Brooks calls essential complexity but when we fail to keep our models separate we end up compounding the issue through accidental complexity.
Bounded context is a pattern that is defined as “The delimited applicability of a particular model. Bounding Contexts gives team members a clear and shared understanding of what has to be consistent and what can develop independently”. See here for more.
Finding where these contexts exist is an opportunity to produce better architected applications because you’re now building much smaller, more focused models. This has a big effect on your mental load too, not having to try and keep that huge, complicated model in your head. It’s also easier to subsequently divide work up between team members, meaning you can work on two or more distinct areas of the system without much danger of stepping on each others toes. The context considered essential to the business, known as the core domain, can be given to those developers on your team with the most experience of software development, and the most business knowledge. This is the context where you try to ensure that you really deliver the right thing and do the thing right, as the saying goes. For those contexts not considered to be core, these can be given to the more junior developers on the team, or perhaps you can buy an off the shelf product that meets the need. It doesn’t really matter, the important thing is that each context can be considered independently allowing decisions to be taken when the time is right for each one, and crucially a decision that might be considered “sub-optimal” applied in one context won’t have repercussions on the others.
Of course good things don’t come without cost, and you will need a way to communicate between boundaries whether that be through database integration (please don’t) or some sort of messaging infrastructure but it’s a small price to pay for the benefit gained from smaller, less complex models. As an aside, I really wouldn’t recommend you use database integration. If you have different bounded contexts all reaching into the same data you basically undo the good work gained from having separated them in the first place because it’s hard to tell what data belongs to which context.
For all the patterns in the book, Bounded Context is the one that has had the biggest influence on me. I could write software without ever using most of the other patterns and I wouldn’t be disadvanteged too much by their ommision but take away bounded context and I’d soon be up to my neck in it. Unfortunately, way too many projects don’t take this into consideration and are up to their neck in it. They start off small and things look like they’re going great but the complexity of that single model growing larger by the day begins to take its toll and before long the project is in trouble. The most important thing, therefore, is to realize that context is definitely king and spending some time upfront searching for those boundaries applicable to your business will pay off in a big way when the dust has settled at the end of a project.