2.5 Context mapping

Context mapping is all about avoiding entanglement: Creating greater efficiency with smaller, more capable components, better APIs, purpose-built data sets, and easily reasoned about services.

Photo by William Olivieri on Unsplash.

Introduction

In the old days, things were simpler. We ran our programs on big computers, we thought about things in a monolithic way. Since everything was running on a single system (quite often, a single CPU) it just made sense to write our code accordingly. There were few if any clear boundaries. We had “spaghetti code” that would reach into other parts of the program and directly change stuff that, frankly, shouldn’t have been changed that way. Everything was entangled, and disentangling it seemed like a neat idea, but mostly unnecessary.

Today’s architectures are obviously much different. Right in the middle of modern architecture is distribution. By that I mean splitting work up across multiple CPUs, multiple servers, often multiple regions. The wider we distribute, the more challenging it becomes to coordinate — and the less possible it is to write anything “spaghetti-like.” Reaching into another component and directly changing things is not only a bad idea, but often impossible.

What’s more, if we do “entangle” all these different components it leads to slow, complex interactions. Too many messages over the wire, and messages that are unnecessarily large, burn up our bandwidth.

Entanglement has become a very bad thing.

Instead, we want to decompose our programs into smaller, easily reasoned about problems. We want to deliver independent services. The more independent we can make each service, the more efficient they become. Lightweight and efficient communication wins out in a largely distributed network. And nicely separated, small programs are easier to figure out, easier to work on, and easier to maintain. They’re just simpler.

The benefits of good context mapping

In the previous chapter, 2.4 Domain modeling, we started to think about how our business needs break down into separate domains. These domains represent contexts that share commonality. A context, in other words, is what knits together a collection of related entities, data, behaviors and their ubiquitous language into a related model. It creates a boundary inside of which we want consistency.

If you use the referral button below, you’ll earn free premium access to Customer Obsessed Engineering. Just three referrals will earn a free month!