Service Boundaries

A Boundary Defines Ownership

After choosing the overall decomposition, you need to establish exactly what each service owns. Inside the boundary are its business rules, data, and decisions about how that data changes. Outside is the contract through which other services can request an allowed operation or obtain a needed representation.

Orders Service owns:
- order state
- order rules
- order changes

Other services use the Orders API

If another service starts changing order state directly or depending on the internal structure of its tables, part of the responsibility has effectively crossed the boundary. The services can no longer evolve independently.

Minimize Conversations Across the Boundary

Boundaries that are too tight show up as a large number of tiny network calls. If one action constantly needs five sequential requests to a neighboring service, perhaps the operation is in the wrong place or the contract exposes too little useful work per call.

At the same time, communication cannot be eliminated completely: services are parts of one product. The goal is not to have no connections, but to make them explicit, stable, and routed through a small set of contracts.

The Boundary Should Match Team Responsibility

When one service has a clear owner, it is easier to make change decisions and maintain contract quality. Blurred responsibility, where several teams constantly edit the internals of one service, often indicates that the technical boundary does not match how the work is really organized.