Boundaries — Why It Matters

The Hardest Problem in Engineering

Ask any experienced engineer what the hardest part of their job is. They won't say "writing code." They'll say some version of:

"Figuring out where one thing ends and another thing begins."

This is the boundary problem, and it is the single most consequential decision in any system. Get the boundaries right and the system is clean, debuggable, changeable, and explainable. Get them wrong and you have a tangled mess that nobody — not even the person who built it — can understand six months later.

An LLM can write code inside a well-defined boundary. It cannot decide where the boundary should be. That's your job.

What Is a Boundary?

A boundary is an answer to the question: "What is this thing responsible for, and what is it NOT responsible for?"

When you say "the authentication module," you are drawing a boundary. Everything about verifying identity is inside. Everything about displaying dashboards is outside. The boundary is the line between them.

Boundaries exist at every level:

This operation handles validating an email address. It does NOT store the email anywhere.
This feature handles user signup. It does NOT handle password resets.
This module handles all authentication. It does NOT handle what the user sees after logging in.
This service handles the entire user account system. It does NOT handle product inventory.

Why Boundaries Are Hard

Everything feels connected

In any real system, almost everything touches something else. A user's name appears on the profile page, in order confirmations, in admin dashboards, in emails. It's tempting to think it's all one thing. It's not — it's one piece of data crossing multiple boundaries.

Premature abstraction

People draw boundaries too early, before they understand the problem. They create a "UserManager" and a "DataProcessor" and an "EventHandler" before they know what the system actually does. These names describe nothing. They bound nothing. They're boundaries without meaning.

Fear of duplication

"But this code does almost the same thing as that code!" So people merge them, destroying two clear boundaries to create one muddled one. Sometimes duplication is the right answer. Two things that happen to look similar today might evolve in completely different directions tomorrow.

What Happens Without Clear Boundaries

The Ripple Effect

You change one thing and seventeen other things break. This happens because responsibilities leaked across boundaries. The payment code shouldn't need to know about the email template format, but someone took a shortcut and now they're coupled.

The "Nobody Understands This" Problem

A new person joins the team. They ask "how does checkout work?" If boundaries are clean, you can point to the checkout module and say "it's all in there." If boundaries are muddy, the answer is "well, it starts here, but then it calls this thing over there, which triggers this other thing, which writes to this shared table that's also used by..." — and the new person learns nothing.

The "Can't Change Anything" Problem

You need to replace the payment provider. If the payment boundary is clean, you swap out the internals and nothing else knows. If the payment logic is scattered across the codebase, you're rewriting half the application.

The "Testing Is Impossible" Problem

You want to verify that order totals are calculated correctly. If calculation is inside a clear boundary with defined inputs and outputs, you test it directly. If calculation is tangled with database access and UI rendering, you have to spin up the entire system just to test arithmetic.

The Hierarchy of Boundaries

Real systems have boundaries nested inside boundaries. Understanding the hierarchy is essential:

Operation

The smallest unit. One focused action.

Validate an email format
Calculate tax on a subtotal
Format a date for display

An operation should do one thing. If you describe it and use the word "and," it might be two operations.

Feature

A user-facing capability composed of operations.

"Sign up" = validate email + validate password + check for duplicate account + create account + send welcome email
"Place order" = validate cart + calculate total + process payment + create order record + send confirmation

A feature is something a user or stakeholder would recognize. "Validate email" is not a feature — "Sign up" is.

Module

A cohesive group of related features.

Authentication module: sign up, log in, log out, reset password, manage sessions
Orders module: browse products, add to cart, checkout, view order history
Notifications module: send email, send push notification, manage preferences

A module should have a clear domain. If you can't name it in one or two words, it might be too broad.

✅ "AuthenticationModule" — clear, you know what's inside
✅ "OrderCalculator" — clear, it calculates orders
✅ "EmailSender" — clear, it sends emails
❌ "Utilities" — what's in here? Everything that didn't fit elsewhere? This is a junk drawer, not a boundary.
❌ "DataManager" — manages what data? All data? This name tells you nothing.
❌ "Helper" — helps with what? This is a confession that you didn't know where to put something.

If you can't name it precisely, you haven't defined it precisely. The name IS the boundary.

Why This Matters For Your Career

In the age of LLMs, the engineer who can say:

"This system needs four modules. Here's what each one does. Here's what each one does NOT do. Here are the connections between them."

...is the engineer who leads projects. The one who asks "should I use React or Vue?" is asking the wrong question. The technology doesn't matter until the boundaries are clear.

Boundaries are the blueprint. Everything else is construction.

Systems Thinking for Engineers