Utilities<\/strong> encapsulate cross-cutting capabilities such as logging, monitoring, security, and observability, allowing these concerns to evolve independently without contaminating core business logic.<\/li>\n<\/ul>\nThese roles are reinforced through explicit communication rules and validated against a small number of core use cases. Over time, this approach localizes change, reduces unintended coupling, and preserves architectural integrity even as systems and organizations grow.<\/p>\n
VBD is most effective in long-lived systems, platform architectures, and integration-heavy environments where change is constant and unavoidable. It provides architects and senior engineers with a clear, practical reference for applying volatility-first architectural thinking at scale.<\/p>\n
\nAbstract<\/h2>\n
Modern software systems operate in environments defined by continuous change \u2014 shifting business requirements, evolving user expectations, regulatory pressure, and rapid technological advancement. Traditional architectural decomposition techniques often fail to account explicitly for change as a primary design force, resulting in brittle systems that degrade over time. Volatility-Based Decomposition (VBD) is an architectural approach that treats change as a first-class concern by identifying, classifying, and isolating areas of anticipated volatility within a system. This paper presents a structured articulation of Volatility-Based Decomposition, covering functional and non-functional volatility, cross-cutting concerns, core use cases, and component role definition. By aligning architectural boundaries with volatility axes, VBD supports the design of flexible, maintainable, and evolvable software systems. The articulation emphasizes modularity, explicit communication rules, and continuous architectural evaluation, providing architects and senior engineers with a practical reference for applying VBD consistently in long-lived systems.<\/p>\n
\n1. Introduction<\/h2>\n
Software architecture exists to manage complexity over time. While many architectural approaches focus on current functional requirements, the dominant force acting on long-lived systems is change. Business models evolve, regulations shift, infrastructure platforms are replaced, and user expectations rise. Architectures that do not explicitly account for these forces tend to accumulate coupling, resist modification, and require costly refactoring or replacement.<\/p>\n
Volatility-Based Decomposition (VBD) addresses this problem by treating change \u2014 not functionality \u2014 as the primary driver of architectural structure. Rather than decomposing systems solely by domain concepts or technical layers, VBD decomposes systems along axes of anticipated volatility. This approach enables architects to localize the impact of change, reduce unintended coupling, and preserve system integrity as requirements evolve.<\/p>\n
This paper provides a practitioner-oriented articulation of VBD. It describes how to identify volatility, align components to volatility boundaries, apply established component roles and communication rules, and validate architectural decisions over time.<\/p>\n
Business strategy evolves continuously. Markets shift. Regulations change. Competitive pressures emerge without warning. To manage this complexity, organizations naturally structure themselves around functional responsibilities such as Sales, Operations, Finance, and Compliance. This functional decomposition brings clarity of ownership, accountability, and decision-making authority.<\/p>\n
Software systems frequently mirror this structure. Teams, codebases, and modules are aligned to functional domains in an attempt to reflect how the business operates. Early in a system’s life, this alignment can be effective, as changes tend to be localized and coordination costs remain manageable.<\/p>\n
Over time, however, tension emerges. The business adapts quickly, while software systems resist change. Most meaningful changes cut across functional boundaries rather than remaining contained within them. Enhancements require coordination across teams and components. Small adjustments trigger broad testing cycles. Risk increases as more parts of the system must move together.<\/p>\n
This divergence exposes a fundamental mismatch: while organizations decompose for accountability, volatility does not respect functional boundaries. Volatility-Based Decomposition addresses this mismatch by aligning architectural boundaries with change dynamics rather than organizational structure alone.<\/p>\n
\n2. Background and Architectural Foundations<\/h2>\n
Volatility-Based Decomposition builds upon established architectural principles, including separation of concerns, information hiding, modularity, and loose coupling. Classic decomposition strategies \u2014 such as layered architectures, service-oriented architectures, and microservices \u2014 implicitly attempt to manage change by isolating responsibilities. However, these approaches often rely on static assumptions about where change will occur.<\/p>\n
VBD makes these assumptions explicit. It acknowledges that not all parts of a system change at the same rate or for the same reasons. By identifying which aspects of a system are most likely to change, architects can proactively structure boundaries that align with those forces, rather than reacting after change has already caused architectural erosion.<\/p>\n
\n3. Defining Volatility in Software Systems<\/h2>\n
For the purposes of this paper, volatility is defined as the likelihood that a given system responsibility, requirement, or implementation detail will change over time, along with the frequency and impact of that change.<\/p>\n
3.1 Functional Volatility<\/h3>\n
Functional volatility refers to changes in system behavior driven by evolving business needs, user feedback, or regulatory requirements. Examples include the addition of new features, modification of existing workflows, or removal of obsolete functionality. Functional volatility is most commonly associated with core use cases and domain logic.<\/p>\n
3.2 Non-Functional Volatility<\/h3>\n
Non-functional volatility concerns changes to system qualities such as performance, scalability, reliability, security, and maintainability. These changes are often driven by external forces, including infrastructure upgrades, platform migrations, or increased usage demands.<\/p>\n
3.3 Cross-Cutting Volatility<\/h3>\n
Cross-cutting concerns \u2014 such as logging, monitoring, authentication, authorization, and error handling \u2014 exhibit volatility that spans multiple components. Changes to these concerns can have widespread impact if not properly isolated.<\/p>\n
3.4 Environmental and Infrastructure Volatility<\/h3>\n
Infrastructure platforms, third-party services, deployment models, and hosting environments are subject to frequent change. Treating these elements as stable foundations often leads to tight coupling between business logic and infrastructure details.<\/p>\n
Figure 1 \u2014 The Four Axes of Volatility and the Component Roles That Encapsulate Them: each role addresses a primary axis of volatility, but the roles work in union \u2014 the Manager orchestrates the what, the Engine executes the how, the Resource Accessor isolates the where, and the Utility provides the with-what. No single role contains all change; the four together localize change across every axis.<\/em><\/p>\ngraph TB\n subgraph axes["Axes of Volatility"]\n FV["Functional<br\/><em>What changes \u2014 workflows and rules<\/em>"]\n NF["Non-Functional<br\/><em>Performance, scalability, reliability<\/em>"]\n CC["Cross-Cutting<br\/><em>With what shared capabilities<\/em>"]\n EV["Environmental<br\/><em>Where data lives and flows<\/em>"]\n end\n\n subgraph roles["Component Roles \u2014 Working in Union"]\n MGR["Manager<br\/>The <strong>What<\/strong><br\/>Stable functional layer \u2014 orchestrates workflow"]\n ENG["Engine<br\/>The <strong>How<\/strong><br\/>Volatile functional layer \u2014 executes business logic"]\n ACC["Resource Accessor<br\/>The <strong>Where<\/strong><br\/>Isolates external boundaries"]\n UTL["Utility<br\/>The <strong>With What<\/strong><br\/>Provides cross-cutting capabilities"]\n end\n\n FV -.->|stable layer| MGR\n FV -.->|volatile layer| ENG\n EV -.->|primary axis| ACC\n CC -.->|primary axis| UTL\n NF -.->|addressed across all roles| MGR\n NF -.->|addressed across all roles| ACC\n\n MGR -->|invokes| ENG\n MGR -->|invokes| ACC\n ENG -->|may call| ACC\n\n UTL -.->|consumed by all| MGR\n UTL -.->|consumed by all| ENG\n UTL -.->|consumed by all| ACC\n\n style FV fill:#f0f4ff,stroke:#0053e2,color:#0053e2,stroke-width:2px\n style NF fill:#fff8e0,stroke:#e6a800,color:#333,stroke-width:2px\n style CC fill:#f0fff0,stroke:#76c043,color:#333,stroke-width:2px\n style EV fill:#e8f5e9,stroke:#2a8703,color:#2a8703,stroke-width:2px\n style MGR fill:#0053e2,color:#fff,stroke-width:0px\n style ENG fill:#ffc220,color:#000,stroke-width:0px\n style ACC fill:#2a8703,color:#fff,stroke-width:0px\n style UTL fill:#76c043,color:#000,stroke-width:0px\n<\/code><\/pre>\n
\n4. Identifying Core Use Cases and Volatility Axes<\/h2>\n
The first step in volatility analysis is identifying core use cases \u2014 the high-level behaviors that define the system’s purpose. Core use cases provide the context necessary to evaluate where change is most likely to occur.<\/p>\n
The term core use case<\/em> is intentionally narrow. In practice, even very large organizations tend to have a surprisingly small number of truly core use cases \u2014 often fewer than five. These represent the fundamental value-producing behaviors of the system, not the many procedural variations that surround them.<\/p>\nWhile business analysts may document dozens or even hundreds of use cases, the majority are not architecturally core. They are alternative paths, conditional flows, exception handling, or policy-driven variants of a much smaller set of essential behaviors. Treating all documented use cases as equal drivers of architecture obscures volatility rather than revealing it.<\/p>\n
Architects should identify volatility axes by:<\/p>\n
\n- Reviewing existing requirements, user stories, and architectural documentation<\/li>\n
- Interviewing stakeholders across business, engineering, and operations<\/li>\n
- Analyzing historical change patterns in similar systems<\/li>\n
- Considering plausible future business and technology shifts<\/li>\n<\/ul>\n
The goal is not to predict exact changes, but to identify where change is likely and why.<\/p>\n
\n5. Volatility-Based Decomposition<\/h2>\n
Volatility-Based Decomposition proceeds through the following steps:<\/p>\n
\n- Identify core use cases that represent the system’s primary value.<\/li>\n
- Enumerate volatility axes across functional, non-functional, cross-cutting, and environmental dimensions.<\/li>\n
- Classify responsibilities based on their likelihood and drivers of change.<\/li>\n
- Define architectural boundaries that align with volatility classifications.<\/li>\n
- Apply established component roles and communication rules to isolate volatile responsibilities from stable ones.<\/li>\n<\/ol>\n
This process results in an architecture where change is localized and predictable, reducing the risk of cascading modifications.<\/p>\n
\n6. Component Roles and Communication Rules<\/h2>\n
Clear component roles and communication rules are essential to preserving volatility boundaries. In addition to Managers, Engines, and Resource Accessors, Volatility-Based Decomposition explicitly recognizes Utilities as a first-class role for isolating cross-cutting volatility. The roles and rules described in this section are derived from Juval L\u00f6wy’s IDesign methodology and component-oriented architecture teachings.<\/p>\n
One aspect of the methodology that is often undervalued is the explicit separation of business logic into two distinct concerns: orchestration and execution. Orchestration governs workflow sequencing, coordination, and intent, while execution encapsulates the business rules and policies that perform the work.<\/p>\n
When orchestration logic and execution logic are interwoven within the same unit, they become change-coupled. A modification to workflow sequencing can force changes in business rule implementation, and a modification to business rules can require restructuring the workflow. This tight coupling increases fragility by expanding the blast radius of change and reducing predictability.<\/p>\n
By separating orchestration from execution, architectures can absorb these changes independently, allowing workflows and business rules to evolve at different rates without destabilizing the system.<\/p>\n
A useful mental model for classifying components is to ask what<\/strong>, how<\/strong>, and where<\/strong>:<\/p>\n\n\n\n| Role<\/th>\n | Question<\/th>\n | Concern<\/th>\n<\/tr>\n<\/thead>\n |
\n\nManager<\/strong><\/td>\nWhat<\/strong> does the system do?<\/td>\n| Orchestration \u2014 workflow, sequencing, intent<\/td>\n<\/tr>\n | \nEngine<\/strong><\/td>\nHow<\/strong> does it do it?<\/td>\n| Execution \u2014 business rules, calculations, policies<\/td>\n<\/tr>\n | \nResource Accessor<\/strong><\/td>\nWhere<\/strong> does data live?<\/td>\n| Integration \u2014 databases, vendors, external systems<\/td>\n<\/tr>\n | \nUtility<\/strong><\/td>\nWith what support?<\/strong><\/td>\n| Cross-cutting \u2014 logging, auth, monitoring, observability<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n If a unit of work decides what<\/em> happens next, it belongs in a Manager. If it computes how<\/em> to do it, it belongs in an Engine. If it reaches out to where<\/em> data or services live, it belongs in a Resource Accessor. If it supports everything but belongs to no domain, it is a Utility.<\/p>\n6.1 Managers<\/h3>\nManagers coordinate operation flow and encapsulate high-level business orchestration. They represent business intent and workflow coordination and should remain stable over time.<\/p>\n Managers MUST NOT<\/strong> perform heavy computation.
\nManagers MUST NOT<\/strong> directly share state.
\nManagers MAY<\/strong> communicate with other managers only through queued, fire-and-forget mechanisms.
\nManagers MAY<\/strong> invoke engines and resource accessors directly.<\/p>\nOnly Managers emit and consume events. Async dispatch, pub\/sub, and queued messaging are Manager-layer concerns. Engines and Resource Accessors operate synchronously within a request.<\/p>\n Illustrative Manager examples:<\/strong><\/p>\n\n- Order Processing Manager<\/em> \u2014 Coordinates the lifecycle of an order by sequencing steps such as validation, pricing, fulfillment, and confirmation without embedding business rules.<\/li>\n
- Customer Interaction Manager<\/em> \u2014 Orchestrates user-facing workflows, invoking engines to fulfill intent and translating technical outcomes into business-level results.<\/li>\n
- Batch Execution Manager<\/em> \u2014 Coordinates scheduled or bulk operations by partitioning work, invoking engines per unit of work, and handling workflow-level retries.<\/li>\n<\/ul>\n
Managers should not implement business rules, perform data aggregation, or contain persistence or integration logic. Their primary responsibility is to express what the system is trying to accomplish, not how it is achieved.<\/p>\n 6.2 Engines<\/h3>\nEngines execute complex business rules, transformations, or computationally intensive operations. They encapsulate the logic most likely to change due to policy shifts, experimentation, or optimization.<\/p>\n Engines MUST NOT<\/strong> communicate with other engines.
\nEngines MUST NOT<\/strong> use queued or pub\/sub mechanisms.
\nEngines MAY<\/strong> call dependent services directly.<\/p>\nIllustrative Engine examples:<\/strong><\/p>\n\n- Pricing Engine<\/em> \u2014 Calculates prices based on rules, tiers, and promotions, evolving frequently as business strategies change.<\/li>\n
- Eligibility or Policy Engine<\/em> \u2014 Evaluates compliance, qualification, or constraint logic driven by regulatory or policy updates.<\/li>\n
- Recommendation or Matching Engine<\/em> \u2014 Performs scoring, ranking, or matching algorithms that change due to tuning or experimentation.<\/li>\n
- Transformation Engine<\/em> \u2014 Converts, normalizes, or enriches data representations without awareness of workflow or persistence.<\/li>\n<\/ul>\n
Engines must not coordinate workflows, interact with messaging infrastructure, or embed persistence concerns. They are invoked by managers and remain unaware of the broader execution context.<\/p>\n 6.3 Resource Accessors<\/h3>\nResource accessors manage interaction with persistence layers, external systems, vendors, and infrastructure-facing resources. They isolate environmental and integration volatility from the rest of the system.<\/p>\n Resource accessors MUST NOT<\/strong> communicate with engines or other resource accessors.
\nResource accessors MUST NOT<\/strong> use queued or pub\/sub mechanisms.
\nResource accessors MAY<\/strong> call dependent services directly.<\/p>\nIllustrative Resource Accessor examples:<\/strong><\/p>\n\n- Order Repository Accessor<\/em> \u2014 Encapsulates database access and schema evolution, shielding the system from persistence changes.<\/li>\n
- External Payment Gateway Accessor<\/em> \u2014 Manages vendor-specific APIs, retries, error translation, and versioning.<\/li>\n
- Messaging or Queue Accessor<\/em> \u2014 Publishes or consumes messages while hiding transport protocols and infrastructure configuration.<\/li>\n
- Configuration or Secrets Accessor<\/em> \u2014 Retrieves environment-specific configuration values without leaking deployment concerns.<\/li>\n<\/ul>\n
Resource accessors must not apply business rules, coordinate workflows, or make policy decisions. Their responsibility is to interact with external resources reliably and predictably.<\/p>\n 6.4 Utilities<\/h3>\nUtilities encapsulate cross-cutting concerns that apply broadly across the system and evolve independently of business workflows. They are orthogonal to core behavior and should remain free of domain-specific knowledge.<\/p>\n Illustrative Utility Component examples:<\/strong><\/p>\n\n- Logging Utility<\/em> \u2014 Provides standardized logging APIs, log formatting, and correlation identifiers without embedding business meaning.<\/li>\n
- Monitoring and Telemetry Utility<\/em> \u2014 Collects metrics, traces, and health signals to support observability without influencing execution flow.<\/li>\n
- Error Classification and Mapping Utility<\/em> \u2014 Normalizes and categorizes errors across components, translating low-level failures into consistent error types.<\/li>\n
- Feature Flag Utility<\/em> \u2014 Enables conditional behavior toggling and experimentation while remaining decoupled from business rules.<\/li>\n
- Security Utility<\/em> \u2014 Supports cryptographic operations, token validation helpers, or hashing functions without making authorization decisions.<\/li>\n<\/ul>\n
Utilities must not coordinate workflows, enforce business policy, or directly interact with external systems on behalf of managers or engines. Their role is to provide shared capabilities that reduce duplication while preserving architectural boundaries.<\/p>\n Figure 2 \u2014 Component Roles and Communication Rules: illustrates the four component roles in VBD \u2014 Managers, Engines, Resource Accessors, and Utilities \u2014 along with their permitted communication patterns and constraints.<\/em><\/p>\nflowchart TB\n MGR["Manager"] -->|invokes| ENG["Engine"]\n MGR -->|invokes| ACC["Resource Accessor"]\n ENG -->|may call| ACC\n\n MGR -.->|consumes| UTL["Utility"]\n ENG -.->|consumes| UTL\n ACC -.->|consumes| UTL\n\n<\/code><\/pre>\n
\n7. Core Use Cases as Architectural Validation<\/h2>\nCore use cases are end-to-end scenarios that exercise all relevant ancillary behaviors. These core use cases serve as validation mechanisms, ensuring that architectural boundaries support real execution paths without introducing hidden coupling or responsibility leakage.<\/p>\n If a core use case requires bypassing defined communication rules, the architecture should be reconsidered.<\/p>\n
\n8. Continuous Evaluation and Architectural Evolution<\/h2>\nVolatility analysis is not a one-time activity. As systems evolve, new volatility axes emerge and existing assumptions may become invalid.<\/p>\n To maintain architectural integrity:<\/p>\n \n- Monitor changes in requirements, infrastructure, and usage patterns<\/li>\n
- Conduct periodic architectural reviews<\/li>\n
- Update volatility classifications and component boundaries<\/li>\n
- Communicate architectural changes clearly to all stakeholders<\/li>\n<\/ul>\n
\n9. Architectural Watchpoints<\/h2>\nVolatility-Based Decomposition is most effective when applied intentionally and proportionally. Like any architectural approach, it introduces forces that must be actively managed over time. The following watchpoints highlight areas that warrant ongoing attention rather than serving as hard limitations.<\/p>\n Decomposition Granularity<\/strong>
\nOver-decomposition can increase cognitive overhead and coordination cost. Architects should monitor whether component boundaries continue to align with meaningful volatility axes or whether decomposition has become finer than the rate of change justifies.<\/p>\nOrganizational Discipline<\/strong>
\nThe effectiveness of VBD depends on consistent adherence to component roles and communication rules. When these boundaries are eroded \u2014 often in the interest of short-term delivery \u2014 volatility begins to leak across components, reintroducing change coupling.<\/p>\nSystem Scale and Lifespan<\/strong>
\nSmaller or short-lived systems may not benefit from full application of VBD. Architects should assess expected system longevity and change rate to determine the appropriate level of rigor.<\/p>\nEvolution of Volatility Axes<\/strong>
\nVolatility is not static. Axes that were once stable may become volatile as business strategy, technology, or regulatory environments change. Periodic architectural review is required to ensure boundaries remain aligned with current realities.<\/p>\n
\n9A. Volatility-Based Decomposition in Real-World Systems<\/h2>\nThe principles of Volatility-Based Decomposition are most clearly demonstrated when applied to real, long-lived software systems operating under continuous change. The following examples are intentionally domain-agnostic and generalized, focusing on architectural forces rather than implementation specifics.<\/p>\n In large enterprise platforms supporting multiple business units, functional requirements evolve unevenly. Core workflows may remain stable for years, while regulatory logic, reporting requirements, and integration points change frequently.<\/p>\n Applying VBD in this context typically reveals:<\/p>\n \n- Managers remain stable, coordinating high-level workflows and orchestration that change infrequently.<\/li>\n
- Engines absorb volatility related to business rules, calculations, policy enforcement, and workflow-specific decisioning.<\/li>\n
- Resource Accessors isolate churn driven by database migrations, schema evolution, vendor swaps, and third-party integrations.<\/li>\n
- Utilities encapsulate cross-cutting concerns such as auditing and compliance logging, which evolve independently of business logic.<\/li>\n<\/ul>\n
This decomposition localizes regulatory- and integration-driven change, preventing widespread refactoring when external requirements shift.<\/p>\n Figure 3 \u2014 Core Use Case: Order Processing: demonstrates how a core use case flows through VBD component roles, with Managers coordinating, Engines executing business logic, Accessors handling persistence, and Utilities providing cross-cutting capabilities.<\/em><\/p>\nsequenceDiagram\n actor Client\n participant OM as OrderManager\n participant VE as ValidationEngine\n participant PE as PricingEngine\n participant OR as OrderRepository\n participant PG as PaymentGateway\n participant LOG as LoggingUtility\n\n Client->>OM: submitOrder(orderRequest)\n OM->>LOG: log(Order received, correlationId)\n OM->>VE: validateOrder(orderRequest)\n VE-->>OM: ValidationResult\n\n alt Validation passed\n OM->>PE: calculatePrice(orderRequest)\n PE-->>OM: PricedOrder\n OM->>OR: saveOrder(pricedOrder)\n OR-->>OM: orderId\n OM->>PG: processPayment(orderId, amount)\n PG-->>OM: PaymentConfirmation\n OM->>LOG: log(Order complete, orderId)\n OM-->>Client: OrderConfirmation\n else Validation failed\n OM->>LOG: log(Order rejected, errors)\n OM-->>Client: ValidationError\n end\n<\/code><\/pre>\nSystems that serve as integration hubs \u2014 connecting internal services, external partners, and third-party APIs \u2014 experience high environmental and infrastructural volatility. APIs version independently, protocols evolve, and reliability characteristics vary widely.<\/p>\n Under VBD:<\/p>\n \n- Managers remain insulated from integration complexity, focusing on orchestration and intent.<\/li>\n
- Engines handle transformation, enrichment, and aggregation logic without direct exposure to external systems.<\/li>\n
- Resource Accessors encapsulate protocol translation, retries, circuit breaking, vendor-specific behavior, and API version management.<\/li>\n<\/ul>\n
This structure allows integrations to be replaced or upgraded with minimal impact beyond the accessor layer.<\/p>\n Example 3: Rapidly Evolving Product Systems<\/h3>\nProduct-focused systems often face intense functional volatility driven by experimentation, user feedback, and market pressure. Performance and scalability concerns may also shift rapidly as adoption grows.<\/p>\n VBD enables such systems to evolve by:<\/p>\n \n- Keeping Managers stable, preserving workflow integrity and orchestration even as underlying behavior shifts.<\/li>\n
- Allowing Engines to absorb frequent algorithmic, rules, and decision-logic changes.<\/li>\n
- Using Resource Accessors to isolate churn in persistence choices, external dependencies, and infrastructure-facing concerns.<\/li>\n
- Using Utilities to adapt cross-cutting needs such as observability and feature flagging without contaminating core logic.<\/li>\n<\/ul>\n
This separation enables rapid iteration while maintaining architectural coherence.<\/p>\n Observed Outcomes<\/h3>\nAcross these scenarios, consistent outcomes emerge:<\/p>\n \n- Change is localized rather than systemic.<\/li>\n
- Architectural intent remains visible and enforceable.<\/li>\n
- Teams can evolve different parts of the system independently.<\/li>\n<\/ul>\n
These results reinforce VBD’s central premise: aligning architectural boundaries with volatility produces systems that are resilient over time.<\/p>\n
\n9B. Practitioner Observations<\/h2>\nThe following observations emerge from applying Volatility-Based Decomposition across multiple systems over extended periods. They are not specific to any organization or domain. Rather, they describe recurring patterns, tensions, and emergent behaviors that practitioners are likely to encounter when VBD is applied consistently as a system matures.<\/p>\n Observation 1: Volatility Migration<\/h3>\nVolatility axes are not permanent. What was stable for years can become intensely volatile due to external forces, and what was once highly volatile can stabilize as a domain matures. A common example is compliance logic: rules that remained unchanged for a decade may suddenly enter a period of rapid, continuous change when new regulation is introduced. Architectures that hardcoded compliance assumptions into Managers or even Utilities find themselves performing invasive surgery across the system. The practical implication is that volatility classification must be revisited periodically. Systems designed under VBD absorb this migration more gracefully because the boundaries already exist \u2014 the work becomes reclassification and, at worst, extraction of logic from one role into another, rather than a fundamental restructuring.<\/p>\n Observation 2: Accessor Accumulation<\/h3>\nAs systems grow, Resource Accessors tend to proliferate. Each new vendor integration, database, external API, or infrastructure dependency typically receives its own Accessor, which is correct according to VBD principles. Over time, however, the sheer number of Accessors can become a management burden. The diagnostic question is whether multiple Accessors share the same volatility profile \u2014 if two Accessors change for the same reasons, at the same rate, and are owned by the same team, consolidation is appropriate. If they change independently, they should remain separate regardless of superficial similarity. The temptation to merge Accessors for tidiness should be resisted when their volatility profiles differ, as doing so reintroduces the coupling VBD was designed to eliminate.<\/p>\n Logic that begins inside a Manager has a natural tendency to migrate into Engines over time. In early development, when the business rules are not yet fully understood, teams often embed decision logic directly in the Manager’s orchestration flow because the rules seem simple or because the team is still discovering what the rules actually are. As the system matures and the rules become clearer, more complex, or more independently volatile, practitioners consistently find themselves extracting that logic into dedicated Engines. This is not a failure of initial design \u2014 it is a healthy and expected progression. VBD accommodates this migration by design: the Manager’s orchestration structure remains intact while the extracted Engine absorbs the volatile logic behind a clean interface.<\/p>\n Observation 4: The Utility Trap<\/h3>\nUtilities are the most frequently misused component role in VBD. Because they are accessible to all other roles and represent “shared” capabilities, there is a persistent temptation to place logic in a Utility simply because multiple consumers need it. The diagnostic is straightforward: if the Utility contains domain knowledge \u2014 if it knows about orders, customers, pricing, or any business concept \u2014 it is not a Utility. It is an Engine or an Accessor that has been misclassified for convenience. True Utilities are domain-agnostic: logging, cryptographic hashing, date formatting, correlation identifier generation, metric collection. When a Utility begins accumulating business-aware conditional logic, it should be reclassified and relocated before it becomes a hidden coupling point that undermines the entire decomposition.<\/p>\n Observation 5: Conway’s Law Alignment<\/h3>\nVBD interacts productively with Conway’s Law \u2014 the observation that system structure tends to mirror organizational communication structure. When component boundaries are aligned with volatility axes, team ownership naturally follows. The team that owns pricing policy owns the Pricing Engine. The team that manages vendor relationships owns the relevant Resource Accessors. This alignment reduces cross-team coordination costs because changes are localized not only architecturally but organizationally. Conversely, when VBD boundaries conflict with team structure, one of two things must change: either the architecture is adjusted to reflect organizational reality, or the organization is restructured to match the architecture. In practice, the most successful outcomes occur when both are considered together.<\/p>\n Observation 6: Emergent Configuration-Drivenness<\/h3>\nSystems built under VBD tend to become configuration-driven over time, even when this was not an explicit design goal. The mechanism is straightforward: because Engines encapsulate business rules behind stable interfaces, and because those rules change frequently, teams naturally begin externalizing rule parameters into configuration rather than modifying code for each change. Pricing tiers become configuration tables. Eligibility thresholds become feature flags. Validation constraints become schema-driven. This emergent behavior is a structural consequence of properly isolating volatile logic \u2014 once the volatility boundary is clean, the path of least resistance for absorbing change shifts from code modification to configuration update. Practitioners should recognize and embrace this tendency rather than treating it as accidental.<\/p>\n Observation 7: The Stability Paradox of Managers<\/h3>\nManagers are designed to be the most stable component in a VBD system, yet they are often the first component written and the last to be understood correctly. Early in a system’s life, Managers tend to accumulate logic that belongs elsewhere \u2014 business rules, data transformation, error handling policy \u2014 because the team has not yet identified which concerns are independently volatile. The paradox is that achieving Manager stability requires the most architectural discipline, precisely because Managers sit at the top of the invocation hierarchy and are the most convenient place to add logic quickly. Teams that enforce Manager stability from the outset consistently report lower long-term maintenance costs, while teams that allow Managers to accumulate non-orchestration logic find themselves performing costly extractions later.<\/p>\n Observation 8: Boundary Pressure as a Health Signal<\/h3>\nIn mature VBD systems, the points where teams feel the most pressure to violate communication rules serve as reliable indicators of architectural misalignment. When an Engine needs to call another Engine, it typically signals that the Manager above them is not properly coordinating the workflow, or that the two Engines should be merged because they share a volatility axis. When a Resource Accessor begins applying business rules, it signals that an Engine is missing from the architecture. Rather than treating boundary violations as failures of discipline alone, experienced practitioners use them as diagnostic signals \u2014 the pressure to violate a rule reveals where the current decomposition no longer matches the system’s actual volatility profile.<\/p>\n
\n10. Conclusion<\/h2>\nVolatility-Based Decomposition provides a disciplined approach to software architecture that treats change as an explicit design constraint rather than an afterthought. By identifying functional, non-functional, cross-cutting, and environmental sources of volatility, architects can align system boundaries with the forces most likely to cause erosion over time.<\/p>\n Through established component roles, strict communication rules, and continuous validation against core use cases, Volatility-Based Decomposition supports the creation of architectures that remain adaptable as systems grow in scale, complexity, and organizational impact.<\/p>\n In many organizations, architectural weakness is revealed not by the initial change itself, but by the unintended side effects that follow. A seemingly localized modification triggers a cascade of downstream impacts, forcing broad testing cycles, emergency fixes, and production instability. These domino effects erode confidence, slow delivery, and increase operational risk.<\/p>\n By aligning architectural boundaries with volatility and validating changes against a small set of core use cases, VBD localizes change and limits its blast radius. While no approach can eliminate change, volatility-based decomposition reduces the likelihood that a single modification will destabilize unrelated parts of the system, preserving architectural integrity and lowering long-term maintenance costs.<\/p>\n As software systems continue to operate in increasingly dynamic environments, architectures that explicitly design for volatility will prove more resilient than those optimized solely for present-day requirements.<\/p>\n
\nAppendix A: Glossary<\/h2>\nBlast Radius<\/strong> \u2014 The extent of system impact caused by a single change. VBD aims to minimize blast radius by aligning boundaries with volatility axes.<\/p>\nChange Coupling<\/strong> \u2014 A condition where modifying one component forces changes in another, even when the two have no logical dependency. Indicates misaligned volatility boundaries.<\/p>\nCommunication Rules<\/strong> \u2014 The explicit constraints governing which component roles may invoke which others, and through what mechanisms. Prevents dependency erosion and preserves volatility isolation.<\/p>\nComponent Role<\/strong> \u2014 One of the four architectural roles assigned to a component based on the type of concern it encapsulates: Manager, Engine, Resource Accessor, or Utility.<\/p>\nCore Use Case<\/strong> \u2014 A high-level system behavior that defines primary business value and exercises all component tiers. Used to validate architectural decisions and communication rules.<\/p>\nDecomposition<\/strong> \u2014 The process of breaking a system into components along boundaries that align with anticipated sources of change.<\/p>\nEngine<\/strong> \u2014 A component that encapsulates business rules, calculations, transformations, and policy logic. Engines answer how<\/em> the system performs its work and absorb functional volatility as business rules evolve.<\/p>\nEnvironmental Volatility<\/strong> \u2014 Change driven by infrastructure platforms, third-party services, vendor APIs, deployment models, and hosting environments.<\/p>\nFunctional Volatility<\/strong> \u2014 Change driven by evolving business behavior, workflows, features, regulations, and user requirements.<\/p>\nInformation Hiding<\/strong> \u2014 Parnas’s principle of decomposing systems based on design decisions likely to change. VBD generalizes this from individual modules to architectural boundaries.<\/p>\nManager<\/strong> \u2014 A component that coordinates workflow, sequencing, and intent. Managers answer what<\/em> the system does and remain stable over time by containing no business logic or infrastructure awareness.<\/p>\nNon-Functional Volatility<\/strong> \u2014 Change driven by performance, scalability, reliability, and other quality-of-service requirements.<\/p>\nOrchestration<\/strong> \u2014 The coordination of workflow steps, sequencing, and intent. Separated from execution in VBD to allow workflows and business rules to evolve independently.<\/p>\nResource Accessor<\/strong> \u2014 A component that isolates interactions with databases, external APIs, vendors, and infrastructure. Resource Accessors answer where<\/em> data and services live and shield the system from environmental volatility.<\/p>\nStability<\/strong> \u2014 The property of a component that changes infrequently relative to others. Managers are designed to be the most stable components in a VBD system.<\/p>\nUtility<\/strong> \u2014 A component that encapsulates cross-cutting concerns such as logging, monitoring, security, and observability. Utilities are orthogonal to business logic and may be called by any other component.<\/p>\nVolatility<\/strong> \u2014 The likelihood, frequency, and impact of change affecting a system responsibility or requirement. The primary organizing force in VBD.<\/p>\nVolatility Axis<\/strong> \u2014 A dimension along which change is expected to occur. The four primary axes are functional, non-functional, cross-cutting, and environmental.<\/p>\nVolatility Boundary<\/strong> \u2014 An architectural seam placed to contain a specific source of change, preventing it from propagating to unrelated components.<\/p>\nVolatility Migration<\/strong> \u2014 The phenomenon where a concern shifts from one volatility axis to another over time, requiring reassessment of component boundaries.<\/p>\n
\nAppendix B: Applicability Checklist<\/h2>\nVolatility-Based Decomposition is particularly well-suited for systems that:<\/p>\n \n- Are expected to evolve over multiple years<\/li>\n
- Operate across changing infrastructure or regulatory environments<\/li>\n
- Support multiple teams or organizational boundaries<\/li>\n
- Require long-term maintainability and extensibility<\/li>\n<\/ul>\n
\nThis appendix presents a fictional but architecturally realistic case study applying Volatility-Based Decomposition to a multi-tenant SaaS billing platform. The system is responsible for generating invoices, calculating charges based on usage and subscription tiers, applying externally-imposed adjustments across multiple jurisdictions, processing payments through multiple providers, and notifying tenants of billing activity.<\/p>\n C.1 Volatility Analysis<\/h3>\nThe first step is identifying what changes and what remains stable.<\/p>\n High Volatility:<\/strong><\/p>\n\n- Pricing rules<\/strong> \u2014 Subscription tiers, volume discounts, promotional offers, and per-unit rates change continuously as business strategy evolves. Pricing data lives behind an accessor because where and how prices are stored is itself a volatility axis.<\/li>\n
- External adjustments<\/strong> \u2014 Tax rates, nexus rules, exemption categories, regulatory fees, and reporting obligations change across jurisdictions independently and unpredictably. External tax services and local databases are isolated behind an accessor.<\/li>\n
- Payment providers<\/strong> \u2014 New providers are added, existing providers change APIs, and regional payment methods must be supported. All provider volatility is isolated behind a single accessor.<\/li>\n
- Invoice storage<\/strong> \u2014 Where and how invoices are persisted \u2014 schema, storage technology, archival strategy \u2014 is isolated behind an accessor owned by the InvoicingEngine.<\/li>\n
- Notification channels<\/strong> \u2014 How tenants are notified (email, SMS, webhook, in-app) changes based on product decisions and tenant preferences.<\/li>\n<\/ul>\n
Low Volatility:<\/strong><\/p>\n\n- Billing lifecycle<\/strong> \u2014 The fundamental sequence of calculating charges, applying adjustments, generating an invoice, collecting payment, and notifying the tenant has remained stable across billing systems for decades.<\/li>\n
- Audit requirements<\/strong> \u2014 The need to maintain a complete, immutable audit trail of all financial transactions is a permanent architectural requirement.<\/li>\n<\/ul>\n
C.2 Component Identification<\/h3>\nManagers:<\/strong><\/p>\n\n- BillingManager<\/strong> \u2014 Orchestrates the end-to-end billing lifecycle: delegates pricing calculation, adjustment application, invoice creation and persistence, payment collection, and tenant notification. Contains no business rules. Expresses intent and sequence only. Fires an async event to NotificationManager after payment is confirmed.<\/li>\n
- NotificationManager<\/strong> \u2014 Orchestrates tenant notification delivery. Receives a billing completion event asynchronously from BillingManager and coordinates the appropriate notification channels. Decoupled from the billing flow \u2014 notification failure does not affect billing outcome.<\/li>\n<\/ul>\n
Engines:<\/strong><\/p>\n\n- PricingEngine<\/strong> \u2014 Encapsulates all pricing logic: subscription tier calculations, usage-based metering aggregation, volume discounts, and promotional adjustments. Retrieves current pricing rules via PriceAccessor. Discounts are an aspect of pricing strategy and belong here.<\/li>\n
- AdjustmentEngine<\/strong> \u2014 Encapsulates all externally-imposed modifications to a priced transaction: tax calculations, regulatory fees, payment processing surcharges, and any other obligations not owned by the business’s pricing strategy. Tax is the primary case \u2014 AdjustmentEngine retrieves rates via TaxAccessor and applies jurisdiction-specific rules \u2014 but the Engine’s boundary is defined by the volatility axis, not the adjustment type. When a new regulatory fee or cross-border surcharge must be applied, AdjustmentEngine is the only component that changes.<\/li>\n
- InvoicingEngine<\/strong> \u2014 Assembles the invoice from priced and adjusted line items, calculates totals, and persists the completed invoice via InventoryAccessor. Owns both creation and persistence \u2014 BillingManager receives only the invoiceId in return.<\/li>\n<\/ul>\n
Resource Accessors:<\/strong><\/p>\n\n- PriceAccessor<\/strong> \u2014 Retrieves pricing rules, tier definitions, and discount schedules from the pricing data store. Isolates PricingEngine from changes in pricing data structure, storage technology, and external pricing service APIs.<\/li>\n
- TaxAccessor<\/strong> \u2014 Retrieves tax rates and jurisdiction rules from external tax services (Avalara, TaxJar) or local tax databases. Isolates AdjustmentEngine from changes in data sources and service provider APIs.<\/li>\n
- InventoryAccessor<\/strong> \u2014 Manages persistence of generated invoices, line items, and billing history. Called by InvoicingEngine, not by BillingManager directly.<\/li>\n
- PaymentAccessor<\/strong> \u2014 Manages integration with external payment providers (Stripe, PayPal, bank ACH, and future providers). Translates provider-specific protocols into a uniform PaymentConfirmation interface.<\/li>\n<\/ul>\n
C.3 Component Architecture<\/h3>\nFigure C.1 \u2014 Billing Platform Component Architecture: BillingManager orchestrates the billing lifecycle, delegating to each Engine and calling PaymentAccessor directly. Each Engine owns its own accessor boundary. NotificationManager receives an async event after payment is confirmed and operates independently of the billing flow.<\/em><\/p>\ngraph TB\n BM[BillingManager]\n PE[PricingEngine]\n TE[AdjustmentEngine]\n IGE[InvoicingEngine]\n PA[PaymentAccessor]\n PRA[PriceAccessor]\n TSA[TaxAccessor]\n ISA[InventoryAccessor]\n NM[NotificationManager]\n\n BM --> PE\n BM --> TE\n BM --> IGE\n BM --> PA\n BM -.->|async event| NM\n\n PE --> PRA\n TE --> TSA\n IGE --> ISA\n\n style BM fill:#0053e2,color:#fff,stroke-width:0px\n style NM fill:#0053e2,color:#fff,stroke-width:0px\n style PE fill:#ffc220,color:#000,stroke-width:0px\n style TE fill:#ffc220,color:#000,stroke-width:0px\n style IGE fill:#ffc220,color:#000,stroke-width:0px\n style PA fill:#2a8703,color:#fff,stroke-width:0px\n style PRA fill:#2a8703,color:#fff,stroke-width:0px\n style TSA fill:#2a8703,color:#fff,stroke-width:0px\n style ISA fill:#2a8703,color:#fff,stroke-width:0px\n<\/code><\/pre>\nC.4 Communication Rules Applied<\/h3>\n\n\n\n| Source<\/th>\n | Target<\/th>\n | Permitted<\/th>\n | Rationale<\/th>\n<\/tr>\n<\/thead>\n | \n\n| BillingManager<\/td>\n | PricingEngine<\/td>\n | Yes<\/td>\n | Manager invokes Engine<\/td>\n<\/tr>\n | \n| BillingManager<\/td>\n | AdjustmentEngine<\/td>\n | Yes<\/td>\n | Manager invokes Engine<\/td>\n<\/tr>\n | \n| BillingManager<\/td>\n | InvoicingEngine<\/td>\n | Yes<\/td>\n | Manager invokes Engine<\/td>\n<\/tr>\n | \n| BillingManager<\/td>\n | PaymentAccessor<\/td>\n | Yes<\/td>\n | Manager invokes Accessor \u2014 after invoice is complete<\/td>\n<\/tr>\n | \n| BillingManager<\/td>\n | NotificationManager<\/td>\n | Yes (async)<\/td>\n | Manager-to-Manager via event \u2014 fire and forget<\/td>\n<\/tr>\n | \n| BillingManager<\/td>\n | InventoryAccessor<\/td>\n | No<\/strong><\/td>\n| Invoice persistence is InvoicingEngine’s responsibility<\/td>\n<\/tr>\n | \n| PricingEngine<\/td>\n | AdjustmentEngine<\/td>\n | No<\/strong><\/td>\n| Engine-to-Engine communication prohibited<\/td>\n<\/tr>\n | \n| PricingEngine<\/td>\n | PriceAccessor<\/td>\n | Yes<\/td>\n | Engine calls its own Accessor<\/td>\n<\/tr>\n | \n| AdjustmentEngine<\/td>\n | TaxAccessor<\/td>\n | Yes<\/td>\n | Engine calls its own Accessor<\/td>\n<\/tr>\n | \n| InvoicingEngine<\/td>\n | InventoryAccessor<\/td>\n | Yes<\/td>\n | Engine calls Accessor to complete its responsibility<\/td>\n<\/tr>\n | \n| PaymentAccessor<\/td>\n | InventoryAccessor<\/td>\n | No<\/strong><\/td>\n| Accessor-to-Accessor communication prohibited<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n BillingManager does not call InventoryAccessor directly. Invoice persistence is encapsulated within InvoicingEngine, which calls InventoryAccessor as part of fulfilling its own responsibility. BillingManager receives only the invoiceId in return.<\/p>\n C.5 Core Use Case Walkthrough: Generate and Process Monthly Invoice<\/h3>\n\n- BillingManager<\/strong> receives a trigger to generate the monthly invoice for a tenant.<\/li>\n
- BillingManager<\/strong> calls PricingEngine<\/strong> with the tenant’s usage data and subscription tier. PricingEngine retrieves current pricing rules via
| | | |
| | | | | | | | |