How to Find Boundaries for Modules, Microservices, or Bounded Contexts
Most domains are too big to be understood and modeled as a whole. Expert software architects, and creators of the Domain Storytelling method, explain how to break down a domain into manageable units.
From the book
From the book
From the book
One of the challenges in building software is structuring it in a way that is comprehensible for developers. If a domain is too big to be understood as a whole, then it is too big to be modeled in software as a whole.
We have seen many large legacy systems that were considered a big ball of mud by their developers. Many of these barely comprehensible software systems are the result of a fundamental misunderstanding: That software should be based on a single, common model of the domain. And that this model is unambiguous. And that it should contain all properties of the real world in as much detail as possible.
A better solution is to have multiple models that cover self-contained parts of a domain instead—called bounded contexts in Domain-Driven Design. This enables the software and the development team to grow.
Finding good boundaries is hard. We found that Domain Storytelling can help: Let domain experts tell you concrete stories about their tasks and workflows. Then, ask them which activities belong together. Consider this domain story depicting, on a coarse-grained level, how an auto leasing company operates (just follow the numbers):
Click to view full-sized image
If we asked a salesperson to show us which of their activities belong together, they would highlight the following part:
Click to view full-sized image
They would also find it easy to name this cohesive group of activities: Offering.
By analyzing the boundaries within the domain, we have found a good basis for designing software architecture and for organizing development teams. Offering is a good candidate for a bounded context that could be implemented as microservice or as a module within a monolithic application.