Service boundaries

A service should own one business capability and its data, and talk to others through APIs or events. Drawing the lines around capabilities, not around tables or teams, is what makes the services independent.

What a session covers

The tutor works through these with you, in conversation and code. A session ends when you have shown them, not when a video does.

Explain what a service should own and why that includes its data
Draw the boundaries for a small domain around capabilities
Spot services that share a database and explain what it costs

In practice

A few lines that show Service boundaries doing its job.

text

Orders service
  owns: orders, line items, order status
  publishes: OrderPlaced, OrderCancelled
  calls: Catalog (prices), Payments (charge)

Catalog service
  owns: products, prices
  never reads the orders tables

The common mistake

Watch for

Splitting one application into services that share a database. They cannot be deployed or changed independently, and every schema change is a cross-team negotiation: a distributed monolith.

What to know first

Your roadmap puts these before Service boundaries, unless you already know them.

How it stays learned

Once a session shows you understand Service boundaries, it comes back for review. Each review takes a minute and tells the memory model how well you still know it.

Day 3First recall, while it is fresh
Day 7Second, a week on
Day 18Last, when it has settled

Where it leads

Topics that build on Service boundaries.

Next in the moduleSpring Cloud Gateway →