Map reasons to change
List the business rules, data ownership, release cadence, and failure modes involved in a capability. Files that share a noun are not necessarily one module; behavior that shares an invariant often is.
Draw the calls and data that cross the proposed boundary. A boundary that requires dozens of synchronous details may be cutting through one cohesive operation.
- Owned invariants
- State transitions
- External dependencies
- Independent release need
Test the contract under failure
Define timeouts, retries, idempotency, version compatibility, and what callers can know after an ambiguous failure. Local function calls hide these questions until a module becomes a service.
Start with a code-level boundary when organizational or scaling needs do not justify a network boundary. The contract can become stronger without adding distributed failure modes.
Change one representative rule and trace how many modules, data stores, tests, and deployables must change together.