How would you identify where to split a large application, using evidence rather than opinion?

What is being tested

Whether you use evidence about what the system actually is rather than opinions about what it should be.

The three sources of evidence

1. Change correlation. Analyse the last several hundred commits: which files and packages change together? Clusters that consistently change together belong together, and the boundaries between clusters are candidate seams.

This is the strongest signal because it describes the system's actual behaviour rather than anyone's intent, and it frequently contradicts the architecture diagram.

2. Data access patterns. Which code touches which tables? A cluster of code touching a cluster of tables with few crossings is a natural boundary; the crossings that appear are the coupling you will have to resolve.

3. Domain language. Where does terminology shift? A word whose meaning changes — "customer" in sales, fulfilment and finance — marks a context boundary, and the code has usually half-respected it already.

The order of extraction

Progressively harder, so extract in this order:

1. Read-only, stateless components. No data ownership to resolve, and reversible.
2. Components with clearly owned data and few cross-boundary queries.
3. Components with a forcing reason — a different resource profile, availability class or compliance boundary.
4. The tangled core. Last, with the most understanding, and possibly never.

The hard part is always data

Code extraction is mechanical. Data is where these projects stall:

• Shared tables need an owner assigned, which is a business decision rather than a technical one.
• Cross-boundary joins become network calls or local projections built from events.
• Transactions spanning the boundary become sagas with compensating actions — new code, new failure modes, new correctness risk.

The sequence that works: assign ownership → route all foreign access through the owner's interface → then physically separate the data. The database can stay shared for a long time while the access is not.

When not to decompose

If the components always change together, extraction adds a network between things that are one thing. The change-correlation analysis tells you this — and the correct response may be to merge components that were split wrongly.