Application Decomposition

Definition

Decomposition identifies boundaries within an existing application and extracts them, either as internal modules or as separate deployables.

Finding the seams

Evidence beats intuition. Three sources, in order of reliability:

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 evidence about what the system actually is, rather than what anyone intended.

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. Crossings that appear are the coupling you will have to resolve.

3. Domain language. Where does terminology shift? A word whose meaning changes marks a context boundary, and it usually corresponds to a seam the code has partially respected already.

The order of extraction

Extract in this order, because each is progressively harder:

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 different resource profile or availability class — the ones with a forcing reason.
4. The tangled core. Last, with the most understanding, and possibly never.

Start with something real enough to prove the path and small enough that being wrong is cheap.

The hard part is always data

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

• Shared tables must be assigned an owner, and the non-owner's access moved behind an interface.
• Cross-boundary joins become network calls or local projections built from events.
• Transactions spanning the new boundary become sagas with compensating actions — new code, new failure modes, new correctness risk.
• Referential integrity across the boundary becomes an application concern.

The sequence that works: assign ownership, route all foreign access through the owner's interface, then physically separate the data. The database can be 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 is to leave them — or to merge components that were split wrongly.

Interview question

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