Module Introduction

1. What This Module Covers

Suppose you have decided to split a system into services. The next question decides whether that split works. Where do the lines go?

Each line you draw is a boundary. A boundary says what one service owns and where it stops. Boundaries are the one part of a microservices system you cannot fix later with a clever pattern. A bad retry policy is a config change. A bad boundary is a migration project.

This is why "how would you split this system?" comes up far more often than any pattern definition. Drawing boxes is easy, and everyone draws roughly the same boxes. What matters is the reasoning behind them. Why these boundaries? What data does each service own? What would make you merge two boxes back together?

💡 Say your reasons out loud as you draw each line. The boxes prove nothing on their own. The reasoning behind each line proves everything.

2. The Lessons

3. Two Terms Used Throughout

1. Coupling. How much one part of the system has to know about, or wait for, another part. Two services are tightly coupled when a change or a failure in one forces a change or a failure in the other. Boundaries exist to reduce coupling. Here is the test. A boundary that does not reduce coupling is just a network hop.
2. Cohesion. How much the things inside one boundary belong together. High cohesion means everything in the service changes for the same reasons. One old rule applies throughout this whole module: things that change together stay together; things that change separately can be separated.

4. Before You Start

Pick a system you know well. If you had to split it into exactly three services, where would the lines go? Which line are you least confident about? Keep that answer, because the capstone will give you a method to check it against.

Start with Bounded Contexts in Plain Words. Almost every conversation about boundaries uses one term from domain-driven design, which is a way of shaping software around how the business itself talks and works. That lesson covers the term, and you will see why it matters for boundaries right away.