# Finding Service Boundaries — Monolith vs Microservices

Source: https://www.skillbyai.com/en/monolith-microservices/d-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.](assets/figures/monolith-microservices/section-4-map.svg) — 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.

```text
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.

**Quiz:** Which is a warning sign of poorly drawn service boundaries?

- [ ] Each service owns a business capability
- [ ] Services expose small, stable APIs
- [x] 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.