From Parnas' paper in the 1970's to microservices in the 2010's, we've always used modularisation as a way to manage complexity in software. And yet, we still end up with big balls of mud. Technical separation alone isn’t enough. We’ve also tried separating into business domains, but it turns out that’s not enough either: software wants to be deeply interconnected, spanning different domains, and doesn’t respect those boundaries.
Bounded Contexts provide an alternative to splitting on domains or on technical modules. We can separate by looking at the semantics. The domain models that underlie our systems, the language that is being used, and the meanings of the terms. We can draw “understandability boundaries”: separations that look at how concepts in our system are understood together (or can be understood autonomously). If we organise the teams along the same lines, then team members will need to understand fewer concepts to be productive. Teams will need less coordination with other teams. Having better semantic boundaries lowers the cognitive load.
Doing this kind of work is not free. But in the 20 years since the concept was introduced in Domain-Driven Design, we’ve developed patterns and heuristics to guide us.
