The wrong cut
A tempting but weak split is by technical layer: a UI service, a logic service, a data service. Every feature then touches all three, so nothing is truly independent.
Decompose by domain
Instead, split by business capability or bounded context. Each service owns a coherent slice of the domain end to end.
- Orders owns order creation and lifecycle.
- Inventory owns stock levels.
- Shipping owns fulfillment.
Why this works
A domain service contains everything it needs to do its job, so a feature change usually lands in one service. This gives high cohesion inside a service and loose coupling between services.
A test
If adding one feature forces edits across many services, your boundaries are probably wrong. Good boundaries follow how the business actually changes.
Key idea
Split services by business capability so each owns a slice end to end, giving high cohesion and loose coupling.