Step 2 — Boundaries first: modules, seams, and dependency direction

Learn how to design boundaries that keep change localized and make refactoring safer.

Step 2 — Boundaries first: modules, seams, and dependency direction

Goal
Learn how to design boundaries that keep change localized and make refactoring safer.

What this step teaches
Good architecture is less about clever patterns and more about controlling change. When boundaries are clear, one part of the system can evolve without forcing changes everywhere else. This is where modules, seams, and dependency direction matter.

A strong team asks:

• Where does this responsibility belong?

• What should change together?

• What must stay independent?

• Which direction should dependencies flow?

The practical rule is simple: dependencies should point inward toward stable policy, not outward toward volatile details.

Core ideas

Modules
A module is a unit of responsibility. It should have one clear reason to change.

Seams
A seam is a place where you can change behavior without rewriting the whole system. Interfaces, adapters, events, and service boundaries are common seams.

Dependency direction
High-level policy should not depend on low-level implementation details. Stable code should not depend on volatile code.

Why this matters for real teams

When boundaries are weak:

• small changes spread across many files

• testing becomes slow and brittle

• refactoring feels risky

• teams step on each other’s work

When boundaries are strong:

• change stays localized

• modules are easier to test

• refactoring becomes safer

• team ownership becomes clearer

Exercise

Draw a 6-box module map of your current system.

Label each box with a major area, such as:

1. UI

2. Application services

3. Domain logic

4. Data access

5. External integrations

6. Shared utilities

Then do two things:

• Mark the highest-churn box

• Propose one new seam that would reduce coupling around that box

Prompt for the learner

Use this template:

• Highest-churn box: __________

• Why it changes often: __________

• What it is tightly coupled to: __________

• New seam to add: __________

• How that seam reduces change spread: __________

Example

• Highest-churn box: Order processing workflow

• Why it changes often: New pricing rules and fulfillment rules

• What it is tightly coupled to: Payment gateway and reporting code

• New seam to add: Payment adapter interface

• How that seam reduces change spread: Payment changes stay behind the adapter instead of leaking into workflow logic

Completion outcome

By the end of this step, the learner should have:

• a visible map of the system’s main modules

• one identified hotspot of change

• one concrete seam they can introduce to make future refactoring safer

Key takeaway

The first design move is not adding patterns. It is drawing boundaries so change has somewhere to stop.