Boundaries — How: The Method

Drawing Boundaries: A Practical Framework

Boundaries don't appear naturally. You have to draw them deliberately. Here is a repeatable four-step process for identifying where boundaries belong in any system.

Step 1: List the Nouns

Take the system description and extract every noun — every "thing" that exists in the domain.

Don't filter yet. Don't decide what's important. Just list every noun you can find.

Example: "A library system where patrons check out books, librarians manage inventory, and overdue books generate fines."

Nouns:

• Patron
• Book
• Librarian
• Inventory
• Fine
• Checkout (the act of checking out — this is a noun too)
• Overdue status (implied)

These nouns are your candidate boundaries. Not all of them will become boundaries, but they are where you start.

Step 2: Group by Responsibility

Ask: "Which nouns are really about the same concern?"

Some nouns are clearly siblings. "Book" and "Inventory" are both about the collection. "Patron" and "Librarian" are both people, but they have fundamentally different responsibilities — so they might belong to different groups.

Create a table:

Each concern is a candidate module.

Step 3: Define the Inside and the Outside

For each candidate boundary, write two lists:

• ✅ Inside: What this module is responsible for. All the actions, data, and rules it owns.
• ❌ Outside: What this module is explicitly NOT responsible for. Name specific things that someone might accidentally put here.

The "Outside" list is the important one. It's easy to say what something does. It's harder — and more valuable — to say what it does NOT do. The outside list is what prevents scope creep.

If you can't clearly write the "outside" list, your boundary is too vague. Go back to step 2 and re-examine.

Step 4: Identify the Connections

Boundaries are not walls — they are membranes. Data flows between them, but only through defined channels.

For each pair of modules that need to communicate, define:

• What data crosses the boundary (be specific — not "user data" but "user ID")
• Which direction it flows (A asks B, or B notifies A, or both)
• What triggers the communication (a user action? a schedule? a state change?)

Draw the connections as arrows with labels. The label should describe the question being asked or the data being passed, not the technical mechanism.

Supporting Concepts

The Responsibility Test

For every piece of logic in your system, ask: "Whose job is it?"

If the answer is clear and singular, your boundaries are right. If the answer is "well, it could be either..." then you have a boundary problem that needs a decision.

Cohesion and Coupling

Two concepts that measure boundary quality:

Cohesion (inside a boundary) — High cohesion = good. Everything inside a boundary should be closely related. If you opened a module and found something unrelated, the boundary is wrong.

Test: "Does every piece inside this boundary serve the same purpose?"

Coupling (between boundaries) — Low coupling = good. Boundaries should depend on each other as little as possible. If changing Module A's internals forces changes inside Module B, they are too tightly coupled.

Test: "If I completely rewrote the inside of this module, would other modules need to change?"

The ideal: high cohesion within boundaries, low coupling between them.

The Naming Test

Can you name each boundary clearly, in 1-3 words, where the name accurately describes EVERYTHING inside?

• ✅ "Authentication" — clear, you know what's inside
• ✅ "OrderCalculation" — clear, it calculates orders
• ❌ "Utilities" — junk drawer, not a boundary
• ❌ "DataManager" — manages what? This name hides confusion
• ❌ "Helpers" — a confession that you didn't know where to put something

The Elevator Test

Can you explain each boundary in one sentence — the kind of sentence you'd say in an elevator?

If your one-sentence explanation includes the word "and" more than once, the boundary might be too wide. If you struggle to fill a sentence at all, it might be too narrow.

What to Look For in the Examples

The following pages work through three complete systems using this four-step method. As you read each one, pay attention to:

1. How many nouns they start with vs. how many boundaries they end with (it's always fewer boundaries than nouns)
2. Where the controversial decisions are — the moments where something could reasonably go in two places
3. What the connection diagram looks like — are there many connections (tightly coupled) or few (loosely coupled)?
4. How the "outside" lists prevent problems — each "NOT responsible for" statement is a bug that won't happen