Volatility-Based Decomposition begins with a simple premise: systems should be organized around how they change.<\/p>\n\n\n\n
Most architectural patterns organize code by technical role. Controllers live in one place, services in another, repositories somewhere else. This produces a clear taxonomy, but it does not explain how change propagates through the system.<\/p>\n\n\n\n
When business rules evolve, workflows shift, or infrastructure changes, these structures often require coordinated modification across multiple layers. The system reflects its organization, but not its volatility.<\/p>\n\n\n\n
Volatility-Based Decomposition addresses that directly by aligning architectural boundaries with the forces that actually drive change.<\/p>\n\n\n\n
In practice, most meaningful change falls into four categories:<\/p>\n\n\n\n
These axes evolve independently. When they are combined within the same component, change in one axis forces unnecessary churn in the others.<\/p>\n\n\n\n
The purpose of decomposition is to prevent that coupling.<\/p>\n\n\n\n
Volatility-Based Decomposition aligns those axes with structural roles:<\/p>\n\n\n\n A Manager coordinates workflow. It determines what happens and in what sequence, but it does not implement business rules and it does not reach directly into infrastructure.<\/p>\n\n\n\n An Engine encapsulates business logic. It performs computation, applies policy, and returns results without awareness of workflow or external systems.<\/p>\n\n\n\n A Resource Accessor isolates interaction with external systems. It translates between internal models and external protocols, shielding the rest of the system from environmental change.<\/p>\n\n\n\n A Utility provides shared capability. Logging, security helpers, monitoring, and observability evolve independently of domain behavior.<\/p>\n\n\n\n The effectiveness of this decomposition depends on a single rule:<\/p>\n\n\n\n State flows down, results propagate up, and there are no horizontal calls within a tier.<\/strong><\/p>\n\n\n\n Managers invoke Engines and Resource Accessors. Engines may call Resource Accessors. Utilities are available to all roles.<\/p>\n\n\n\n Engines do not call other Engines. Resource Accessors do not call other Resource Accessors. Managers do not share state laterally.<\/p>\n\n\n\n This rule preserves the independence of volatility axes. When it is violated, change begins to propagate across boundaries.<\/p>\n\n\n\n Many teams produce something like this. They are not writing procedural scripts. They are applying clean architecture. They have a domain model, proper interfaces, dependency injection, and repository abstractions. Payment and notification are behind ports. Infrastructure concerns are isolated from business logic.<\/p>\n\n\n\n The structure is defensible. This is what careful, experienced work looks like.<\/p>\n\n\n\n Interfaces everywhere. Domain model properly isolated. Adapters behind ports. This is architecturally literate code. It will pass any review.<\/p>\n\n\n\n And it still has the same fundamental problem.<\/p>\n\n\n\n The The application service still coordinates everything synchronously. Payment goes through The ports give you the ability to swap implementations. They do not give you the ability to evolve use cases independently.<\/p>\n\n\n\n The abstraction addressed the wrong boundary.<\/strong><\/p>\n\n\n\n Clean architecture asks: where does the dependency point? Volatility-Based Decomposition asks: what forces this to change? These are different questions, and they produce different structures.<\/p>\n\n\n\n Under Volatility-Based Decomposition, the same system is structured differently.<\/p>\n\n\n\n Here, the OrderManager<\/strong> coordinates the workflow but does not embed business logic or infrastructure concerns.<\/p>\n\n\n\n The ValidationEngine<\/strong> and PricingEngine<\/strong> operate independently. Each consumes only the data it requires through its own Resource Accessor. Neither Engine depends on the other.<\/p>\n\n\n\n Persistence is isolated. External integrations are isolated. And critically, payment and notification are triggered asynchronous workflows<\/strong>, not embedded steps in the primary request path.<\/p>\n\n\n\n This breaks the coupling at the use-case level.<\/p>\n\n\n\n Order submission is now independent of payment processing. Payment is independent of notification. Each workflow can evolve, fail, retry, or scale without forcing coordinated change in the others.<\/p>\n\n\n\n A compliance requirement arrives: high-value orders must be validated against a fraud rules engine before submission.<\/p>\n\n\n\n This is a single, well-scoped requirement. It touches one domain concern: validation. Watch what happens when it lands on each system.<\/p>\n\n\n\n The fraud check result must flow from Red<\/strong> \u2014 must change to implement the requirement. Orange<\/strong> \u2014 potentially affected depending on whether fraud status gates payment authorization. The change is functionally local but structurally diffuse, because the shared aggregate connects everything that touches it.<\/p>\n\n\n\n The RulesAccessor<\/strong> gains a query for fraud rules. The ValidationEngine<\/strong> gains the logic to evaluate them. The rules themselves live in the Rules Store, which already exists behind the accessor boundary.<\/p>\n\n\n\n Two components change. Nothing else is aware a new rule exists.<\/p>\n\n\n\n OrderManager<\/strong> does not know a new rule exists. PricingEngine<\/strong> is untouched. PaymentManager<\/strong> is untouched. The change is contained to the component that owns validation behavior \u2014 because that is what the boundary was designed to isolate.<\/p>\n\n\n\n Now consider what happens if the fraud check is slow. Engines and Resource Accessors are always called synchronously by their consuming Manager \u2014 async behavior is a Manager-level concern. The solution is not a new Manager. It is a new operation on the OrderManager itself: a validation entry point at the API surface that accepts the same order object. The OrderManager runs the ValidationEngine and RulesAccessor synchronously, then emits an event with the result. The OrderManager listens to its own events and picks up from there \u2014 continuing to process if validation passed, or surfacing the issue if it did not.<\/p> The client submits and waits. If something fails, they receive an event. If everything processes normally, they are none the wiser. The internal coordination is invisible to them \u2014 and invisible to every other component in the system.<\/p> In the clean architecture system, the same change requires restructuring how the application service coordinates its calls \u2014 the shared aggregate is the coordination point, so any change to when or how results flow through it touches the same components that already changed.<\/p>\n\n\n\n If the rules live behind an accessor, they are already data. What if the ValidationEngine never needed to change at all \u2014 because the rules were configuration loaded at runtime? The boundary does not just contain change. It creates the conditions under which some changes stop being code changes entirely.<\/p><\/blockquote><\/figure>\n\n\n\n The difference between these two designs is not stylistic. It is behavioral under change.<\/p>\n\n\n\n Volatility-Based Decomposition does not eliminate change. It ensures that change behaves predictably.<\/p>\n\n\n\n That is the difference between a system that evolves and one that resists evolution.<\/p>\n\n\n\n That is the point.<\/p>\n\n","protected":false},"excerpt":{"rendered":" Volatility-Based Decomposition begins with a simple premise: systems should be organized around how they change. Most architectural patterns organize code by technical role. Controllers live in one place, services in another, repositories somewhere else. This produces a clear taxonomy, but it does not explain how change propagates through the system. When business rules evolve, workflows … Read more<\/a><\/p>","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_uag_custom_page_level_css":"","footnotes":""},"categories":[3],"tags":[],"methodology":[],"class_list":["post-183","post","type-post","status-publish","format-standard","hentry","category-tutorials"],"uagb_featured_image_src":{"full":false,"thumbnail":false,"medium":false,"medium_large":false,"large":false,"1536x1536":false,"2048x2048":false,"trp-custom-language-flag":false,"post-thumbnail":false,"hf-card":false,"hf-hero":false},"uagb_author_info":{"display_name":"William Christopher Anderson","author_link":"https:\/\/harmonic-framework.com\/es\/author\/admin\/"},"uagb_comment_info":0,"uagb_excerpt":"Volatility-Based Decomposition begins with a simple premise: systems should be organized around how they change. Most architectural patterns organize code by technical role. Controllers live in one place, services in another, repositories somewhere else. This produces a clear taxonomy, but it does not explain how change propagates through the system. When business rules evolve, workflows…","_links":{"self":[{"href":"https:\/\/harmonic-framework.com\/es\/wp-json\/wp\/v2\/posts\/183","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/harmonic-framework.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/harmonic-framework.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/harmonic-framework.com\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/harmonic-framework.com\/es\/wp-json\/wp\/v2\/comments?post=183"}],"version-history":[{"count":21,"href":"https:\/\/harmonic-framework.com\/es\/wp-json\/wp\/v2\/posts\/183\/revisions"}],"predecessor-version":[{"id":650,"href":"https:\/\/harmonic-framework.com\/es\/wp-json\/wp\/v2\/posts\/183\/revisions\/650"}],"wp:attachment":[{"href":"https:\/\/harmonic-framework.com\/es\/wp-json\/wp\/v2\/media?parent=183"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/harmonic-framework.com\/es\/wp-json\/wp\/v2\/categories?post=183"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/harmonic-framework.com\/es\/wp-json\/wp\/v2\/tags?post=183"},{"taxonomy":"methodology","embeddable":true,"href":"https:\/\/harmonic-framework.com\/es\/wp-json\/wp\/v2\/methodology?post=183"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Role<\/th> Concern<\/th> Responsibility<\/th><\/tr><\/thead> Manager<\/td> Orchestration<\/td> Workflow coordination and intent<\/td><\/tr> Engine<\/td> Functional<\/td> Business logic execution<\/td><\/tr> Resource Accessor<\/td> Environmental<\/td> External system interaction<\/td><\/tr> Utility<\/td> Cross-cutting<\/td> Shared capabilities<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Communication Discipline<\/h2>\n\n\n\n
What a Well-Engineered System Gets Wrong<\/h2>\n\n\n\n
flowchart TB\n classDef app fill:#0b57d0,color:#ffffff,stroke:#0842a0,stroke-width:2px;\n classDef domain fill:#fbbc04,color:#202124,stroke:#c49000,stroke-width:2px;\n classDef port fill:#188038,color:#ffffff,stroke:#146c2e,stroke-width:2px;\n classDef external fill:#f8f9fa,color:#3c4043,stroke:#cfd1d4,stroke-width:1.5px;\n\n AS["OrderApplicationService"]:::app\n\n OA["Order (Aggregate)"]:::domain\n VS["ValidationService"]:::domain\n PS["PricingService"]:::domain\n\n IPG["IPaymentGateway"]:::port\n IOR["IOrderRepository"]:::port\n\n PG["PaymentAdapter"]:::external\n ORDERR["OrderRepository"]:::external\n\n AS --> OA\n AS --> VS\n AS --> PS\n AS --> IPG\n AS --> IOR\n\n VS --> OA\n PS --> OA\n\n IPG --> PG\n IOR --> ORDERR<\/code><\/pre>\n\n\n\nOrder<\/code> aggregate is shared. ValidationService<\/code> and PricingService<\/code> both depend on it. When pricing logic changes \u2014 a new discount model, a regulatory requirement, a currency rule \u2014 the aggregate changes. When the aggregate changes, validation is affected. Not because validation has anything to do with pricing, but because they share a model.<\/p>\n\n\n\nIPaymentGateway<\/code>, which is clean, but it happens in the same request as order submission. When payment SLA requirements change \u2014 timeouts, retry policy, regional routing \u2014 the order submission workflow must change with it. The interface hid the infrastructure. It did not isolate the use case.<\/p>\n\n\n\nThe Same System After Volatility-Based Decomposition<\/h2>\n\n\n\n
flowchart TB\n classDef manager fill:#0b57d0,color:#ffffff,stroke:#0842a0,stroke-width:2px;\n classDef engine fill:#fbbc04,color:#202124,stroke:#c49000,stroke-width:2px;\n classDef accessor fill:#188038,color:#ffffff,stroke:#146c2e,stroke-width:2px;\n classDef external fill:#f8f9fa,color:#3c4043,stroke:#cfd1d4,stroke-width:1.5px;\n\n subgraph APP["Order Processing Application (Volatility-Aligned)"]\n direction TB\n\n OM["OrderManager"]\n\n VE["ValidationEngine"]\n PE["PricingEngine"]\n\n PM["PaymentManager"]\n NM["NotificationManager"]\n\n IA["ItemAccessor"]\n RA["RulesAccessor"]\n PRA["PriceAccessor"]\n OA["OrderAccessor"]\n end\n\n subgraph EXT["External Systems"]\n direction LR\n IDS["Item Data Source"]\n RDS["Rules Store"]\n PDS["Pricing Data Source"]\n ODS["Order Store"]\n PG["Payment Provider"]\n NS["Notification Service"]\n end\n\n OM --> VE\n VE --> IA\n VE --> RA\n\n OM --> PE\n PE --> PRA\n\n OM --> OA\n\n OM -.->|async| PM\n OM -.->|async| NM\n\n IA --> IDS\n RA --> RDS\n PRA --> PDS\n OA --> ODS\n PM --> PG\n NM --> NS\n\n class OM,PM,NM manager\n class VE,PE engine\n class IA,RA,PRA,OA accessor\n class IDS,RDS,PDS,ODS,PG,NS external<\/code><\/pre>\n\n\n\nChange in Practice<\/h2>\n\n\n\n
In the Clean Architecture System<\/h3>\n\n\n\n
ValidationService<\/code> through the shared Order<\/code> aggregate so the application service can act on it. The aggregate changes to carry fraud status. The application service changes to branch on that status. And if fraud status gates payment authorization, the payment path changes too \u2014 not because payment logic changed, but because the shared model connects them.<\/p>\n\n\n\nflowchart TB\n classDef changed fill:#d93025,color:#ffffff,stroke:#b31412,stroke-width:2px;\n classDef affected fill:#e37400,color:#ffffff,stroke:#b06000,stroke-width:2px;\n classDef unchanged fill:#f1f3f4,color:#9aa0a6,stroke:#dadce0,stroke-width:1px;\n classDef lChanged fill:#d93025,color:#ffffff,stroke:#b31412,stroke-width:2px,font-size:11px;\n classDef lAffected fill:#e37400,color:#ffffff,stroke:#b06000,stroke-width:2px,font-size:11px;\n classDef lUnchanged fill:#f1f3f4,color:#9aa0a6,stroke:#dadce0,stroke-width:1px,font-size:11px;\n\n subgraph APP["Order Processing Application (Layered)"]\n direction TB\n\n AS["OrderApplicationService"]:::changed\n\n OA["Order (Aggregate)"]:::changed\n VS["ValidationService"]:::changed\n PS["PricingService"]:::unchanged\n\n IPG["IPaymentGateway"]:::affected\n IOR["IOrderRepository"]:::unchanged\n\n PG["PaymentAdapter"]:::affected\n ORDERR["OrderRepository"]:::unchanged\n\n AS --> OA\n AS --> VS\n AS --> PS\n AS --> IPG\n AS --> IOR\n\n VS --> OA\n PS --> OA\n\n IPG --> PG\n IOR --> ORDERR\n end\n\n subgraph LEGEND["Legend"]\n direction LR\n LC["Changed"]:::lChanged\n LA["Affected"]:::lAffected\n LU["Unchanged"]:::lUnchanged\n end<\/code><\/pre>\n\n\n\nIn the VBD System<\/h3>\n\n\n\n
flowchart TB\n classDef changed fill:#d93025,color:#ffffff,stroke:#b31412,stroke-width:2px;\n classDef unchanged fill:#f1f3f4,color:#9aa0a6,stroke:#dadce0,stroke-width:1px;\n classDef unchangedExt fill:#f8f9fa,color:#c5c8cb,stroke:#ebebeb,stroke-width:1px;\n classDef lChanged fill:#d93025,color:#ffffff,stroke:#b31412,stroke-width:2px,font-size:11px;\n classDef lUnchanged fill:#f1f3f4,color:#9aa0a6,stroke:#dadce0,stroke-width:1px,font-size:11px;\n\n subgraph APP["Order Processing Application"]\n direction TB\n\n OM["OrderManager"]:::unchanged\n\n VE["ValidationEngine"]:::changed\n PE["PricingEngine"]:::unchanged\n\n PM["PaymentManager"]:::unchanged\n NM["NotificationManager"]:::unchanged\n\n IA["ItemAccessor"]:::unchanged\n RA["RulesAccessor"]:::changed\n PRA["PriceAccessor"]:::unchanged\n OA["OrderAccessor"]:::unchanged\n end\n\n subgraph EXT["External Systems"]\n direction LR\n IDS["Item Data Source"]:::unchangedExt\n RDS["Rules Store"]:::unchangedExt\n PDS["Pricing Data Source"]:::unchangedExt\n ODS["Order Store"]:::unchangedExt\n PG["Payment Provider"]:::unchangedExt\n NS["Notification Service"]:::unchangedExt\n end\n\n OM --> VE\n VE --> IA\n VE --> RA\n\n OM --> PE\n PE --> PRA\n\n OM --> OA\n\n OM -.->|async| PM\n OM -.->|async| NM\n\n IA --> IDS\n RA --> RDS\n PRA --> PDS\n OA --> ODS\n PM --> PG\n NM --> NS\n\n subgraph LEGEND["Legend"]\n direction LR\n LC["Changed"]:::lChanged\n LU["Unchanged"]:::lUnchanged\n end<\/code><\/pre>\n\n\n\nThe Same Requirement, Side by Side<\/h3>\n\n\n\n
Component<\/th> Clean Architecture<\/th> VBD<\/th><\/tr><\/thead> Application Service \/ Manager<\/td> Changes \u2014 must handle fraud result<\/td> No change<\/td><\/tr> Shared Domain Model \/ Aggregate<\/td> Changes \u2014 must carry fraud status<\/td> Does not exist as shared model<\/td><\/tr> Validation logic<\/td> Changes<\/td> Changes (ValidationEngine only)<\/td><\/tr> Rules data access<\/td> New or modified (on aggregate)<\/td> Changes (RulesAccessor only)<\/td><\/tr> Payment path<\/td> Potentially affected<\/td> No change<\/td><\/tr> Pricing logic<\/td> Untouched but coupled via aggregate<\/td> Untouched and structurally isolated<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Why This Matters<\/h2>\n\n\n\n
\n