Good Fences Make Good Neighbors

Speaking of bounded contexts, I love contexts, or more precisely, I love the idea of bounded contexts. Boundaries are great tools for simplification. They help you maintain separation of concerns and isolation both inside a module and between modules. And that's domain driven design. One of the things you'll find when you dig a little deeper into microservice architecture is that everyone talks about Bounded Contexts and Domain Driven Design. The important thing to remember though is that regardless of the "architecture" you're building, good architecture is good architecture. Microservices might give you more scale-out, but you pay for it with more cognitive load.

Most of the things we do with computers these days is a simulation of some real-world thing, whether it's passing notes in class, driving a car, or high energy physics. Some are mostly in our heads, some are very dynamic, and some have more interaction with the physical world than others. They have different levels of detail, but they're all models or abstractions that we simulate. And like any other model, they have boundaries. Things that are part of the model and things that aren't. And the clearer the boundaries, the easier it is to know what's in and what's out. And that's a Bounded Context. And once you know the Bounded Context for each model it's much easier to put them together into a model of the entire system. 

Of course, scope matters. Bounded Contexts isn't something that only applies to architects or how microservices fit together. You should use Bounded Contexts at every scale. Functions in a class should have clear boundaries as well. It makes no more sense to have the function that sets the input path print out the final report than it does to have your sensor fusion service control emergency braking.

So know what your boundaries are. And if they're not clear, find the person on the other side and work to firm them up. You'll both be happier.