Understandability boundaries are separations that look at how concepts in our system are understood together (or autonomously).
By
Mathias Verraes
Published on 29 March 2023
The new DDD Australia user group just had its first meetup, and I was invited to speak. A major bottleneck for fast high quality software development is that people in the organisation don’t understand their systems and domains well enough. So I did a (mostly improvised) session on using Bounded Contexts to manage meaning and understandability.
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 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.