Lesson 10 / 25

Finding Service Boundaries

Draw service boundaries around capabilities with high cohesion and low coupling.

Cohesion inside, loose coupling outside

Good service boundaries put things that change together in the same service and keep the interfaces between services small and stable. Start from business capabilities and bounded contexts, not from technical layers or database tables. Warning signs of bad boundaries: entity services (a "Customer service" and an "Order service" that are just CRUD wrappers around tables, so every feature needs changes in several of them); chatty interfaces where one user action triggers dozens of calls between two services; shared database tables; and services that must always be deployed together. Useful techniques: event storming workshops to find domain events and aggregates; looking at version history to see which files change together; and asking which team would own the service. Aim for services a team can understand completely and change without asking permission.

Cohesive services with thin connections

Tightly related parts sit together; only a few stable connections cross service boundaries.

Three clusters of tightly linked dots, each cluster circled, with only a single thin line between neighbouring clusters. — Figure 4.1 — High cohesion inside services, low coupling between them.

Entity services versus capability services

The capability split lets one team deliver "apply a coupon" alone.

entity split (poor)                  capability split (better)
-----------------------------------  ----------------------------------------
customer-service  (CRUD customers)   identity        sign-up, login, profiles
product-service   (CRUD products)    catalogue       browse, search, product pages
order-service     (CRUD orders)      checkout        cart, pricing, coupons, place order
price-service     (CRUD prices)      fulfilment      picking, shipping, tracking
                                     billing         invoices, refunds, payouts
"apply a coupon" touches 3 services   "apply a coupon" touches checkout only

Check change history

Run a quick analysis of which files changed together over the last year (git log --name-only). Files that always change together belong in the same service; splitting them guarantees coordinated releases.

Quick check: Which is a warning sign of poorly drawn service boundaries?

Each service owns a business capability
Services expose small, stable APIs
Most features require coordinated changes in several services
Teams can deploy alone

Answer

Most features require coordinated changes in several services — Frequent multi-service changes show that cohesive logic was split across boundaries.