Information Hiding

Parnas's formulation, and it is more precise than the usual reading of modularity. The criterion for decomposition is not functional steps — it is which design decisions are likely to change. Each such decision is hidden inside one module, so a change touches one place.

That reframes the boundary question productively. Instead of "what are the parts of this process", ask "what is likely to change independently" — the storage engine, the pricing rule, the external partner's protocol, the report format. Each becomes a module with the volatile decision inside it and a stable interface outside.

The interface is the contract; the hidden decision is the point. A module whose internals are visible and depended upon is not hiding anything, and changing it breaks callers regardless of what the interface says.

Applied at service scale, this is why sharing a database defeats service boundaries: the schema is a hidden decision that has become a public contract, so neither service can change it independently and the modularity is nominal.

The failure mode to watch for is decomposition by technical layer — all the data access in one module, all the validation in another — which spreads every business change across every module and produces the opposite of what was intended.