microservices-boundarieslisted

# Microservices boundaries The hard part of microservices is not building services; it is drawing the lines between them. Wrong boundaries produce a distributed monolith: all the operational cost of microservices with none of the independence, where every change touches three services and they deploy in lockstep. ## Method 1. **Split by business capability, not technical layer.** A service owns a domain (ordering, billing, inventory) end to end, not a tier (there is no "database service" and no "API service"). Bounded contexts from the domain (see domain-driven-design) are the natural seams; org structure will shape them anyway (Conway's law), so design the boundaries and the team boundaries together. 2. **Give each service sole ownership of its data.** One service, one database, no other service reaching into it: services collaborate through APIs and events (see event-driven-architecture), never shared tables. A shared database is the distributed monolith's spine: it couples deploys, schemas, and failures across every service that touches it. 3. **Test boundaries against change and chattiness.** Good boundaries mean most changes fit inside one service (high cohesion) and services talk coarsely (low coupling: see coupling-analysis). Warning signs of wrong lines: a feature always changing the same three services together, or two services making dozens of synchronous calls per request (that chatter is one service split