Encapsulate what is bound to change, and change stops breaking the system.
Every software system contains areas that are certain to change during its life: a pricing rule, a regulatory constraint, a communication protocol, a data format, a third-party service. We call each such area a volatility: a software area bound to be broken when modifications are performed.
Volatilities are not exotic. They are the ordinary consequence of a business that lives in a moving market. The question is never whether these areas will change. The question is what the change will cost when it arrives, and that cost is decided by the system's decomposition, years before the change is requested.
Nearly all software written today is decomposed by function: the requirements list is broken into features, and each feature becomes a component. It feels natural, and it is the root cause of the industry's chronic failures.
Business requirements are constantly altered by market dynamics, competitors and regulatory updates. A decomposition built on them inherits their instability: the structure of the system is coupled to the least stable thing the business owns.
When components mirror functions, one changed requirement cuts across many components at once. Each modification erodes the system's resilience, breeds regression bugs, and makes the next change harder than the last.
Maintenance costs and response times follow an exponential curve as the functional structure decays, until the only remaining option is a full rewrite that writes off the entire accumulated investment.
The business domain is stable in a way the requirements list never is. From it we identify the system's Core Use Cases and extract the volatilities list.
Each building block hides its allocated volatilities behind a stable interface, and together the blocks cover all aspects of the business domain. A thin Abstraction Layer enforces total separation between stable Business Logic Components and volatile external behavior.
A feature is an integration of existing blocks. When a requirement changes, the impact is confined to the Orchestration Layer; the core components remain insulated and untouched. New capabilities arrive in days, and the architecture itself never changes.
SOLID is the set of five design principles that keeps each building block clean on the inside, the way Volatility-Based Decomposition keeps the system clean on the outside. We apply them strictly, as structure rather than guidelines:
Parnas supplies the criterion for where to draw the boundaries; SOLID supplies the discipline that keeps those boundaries intact through decades of change.
Volatility-Based Decomposition is the first step of every architecture we deliver: from the volatilities list to a validated framework, a Critical Path project design, and detailed design that runs hand in hand with coding.
How We Design Software Architecture