Bounded Contexts
It was brought up indirectly in a comment on my last post … the idea of a Ubiquitous Language seems like it is too all encompassing. Indeed it is – unless you are working on a very simple application, one language just isn’t enough. Not only that, but a single “mammoth model” will also be too large, unwieldy, and eventually turn into a Big Ball of Mud. That is where the idea of Bounded Context come into the game.
Bounded Contexts in DDD is one of the “advanced” topics, it doesn’t even appear in the book until well over halfway. However, I am going to introduce it now, so that later in this series, the terms don’t become an obstacle… in the book you could flick a few hundred pages ahead, here you don’t have that luxury. Feel free to skip this post until later if it doesn’t make much sense now.
Suffice to say you could model your entire domain as a single thing, with a language to cover everything, but if you look at the business you are trying to model, it is unlikely that is how they see things.
An example of Context here would be within an ecommerce system. Although you could model this as a single system, it would also warrant splitting into separate Contexts. Each of these areas within the application have their own Ubiquitous Language, their own Model, and a way to talk to other Bounded Contexts to obtain the information they need.
Example Ecommerce Contexts
Well the obvious starting point would be the customer facing Context – let’s call this the Shopping Context – this is the part of the application that lets a customer browse the catalogue, search for items, pick items, and put them in their shopping basket.
You may be thinking this is it for a simple ecommerce system – and for a simple system it probably is. However on larger systems there are other Contexts that should probably come into play
When the customer clicks “checkout” then we need to process that order, this is going to involve the Ordering Context to take the shopping basket, process the payment and to create the relevant instructions for picking, the Inventory Context(which may have been involved earlier to display “items in stock”) to reserve the items in the warehouse, and the list may go on depending on the scale of the entire application.
Each of these Bounded Contexts has a specific responsibility, and can operate in a semi-autonomous fashion. By splitting these apart it becomes more obvious where logic should sit, and we can avoid that BBOM.
Bounded Context or Context?
The term Context is a general description of a grouping of concepts, the term Bounded Context is more specific – aBounded Context is an area of your application which has explicitly defined borders, has it’s own model, has it’s own Model, and maintains it’s own code. Within the Bounded Context everything should be strictly consistent.
Usually, we can use the terms Context and Bounded Context interchangeably, though I tend to talk in terms of Contextabout the business side of things, and the term Bounded Context about the technical implementation.
In essence, a Bounded Context is an application in it’s own right. By splitting your large application into many Contexts, you gain all the advantages of modularity, separation of concerns and loose coupling – but on a much larger scale than many developers often think.
Surely Bounded Context’s Must Interact?
Indeed they do need to. Within DDD this is done using a Context Map. Again, I will skip the details for now, but suffice to say, a Context Map is a clearly defined way of talking between Bounded Contexts. The book has a number of examples of how this could be implemented, and many more will become apparent as you progress. The Context Map is the contract yourBounded Context provides to the outside world, other Bounded Contexts
In Conclusion
We skipped a fair way ahead here, so don’t get too stuck up on Contexts, just bear in mind they exist, and they resolve issues around conflicting Ubiquitous Language terms, allow Models to focus on specific problems, and provide a loosely coupled application architecture.