Modern software systems rarely fail because of poor initial design; they fail because change accumulates faster than the architecture can absorb it. VBD addresses this by treating change as the primary organizing force in system design.<\/p>\n\n\n\n
Rather than decomposing systems by domain concepts or technical layers, VBD organizes architectural boundaries around anticipated sources of volatility. Components that change for the same reason \u2014 and at the same rate \u2014 belong together. Components that change for different reasons belong apart, regardless of their current functional relationship.<\/p>\n\n\n\n
Business strategy evolves continuously. Markets shift. Regulations change. Organizations naturally structure themselves around functional responsibilities \u2014 Sales, Operations, Finance \u2014 and software frequently mirrors that structure. Early in a system’s life, this alignment works. Over time, tension emerges: most meaningful changes cut across functional boundaries rather than remaining contained within them. VBD addresses this mismatch by aligning architectural boundaries with change dynamics rather than organizational structure alone.<\/p>\n\n\n\n
| Axis<\/th> | Description<\/th> | Examples<\/th><\/tr><\/thead> | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Functional<\/strong><\/td>| Changes in system behavior driven by evolving business needs<\/td> | New features, modified workflows, regulatory changes<\/td><\/tr> | Non-Functional<\/strong><\/td> | Changes to system qualities<\/td> | Performance, scalability, reliability, security<\/td><\/tr> | Cross-Cutting<\/strong><\/td> | Changes spanning multiple components<\/td> | Logging, monitoring, authentication, error handling<\/td><\/tr> | Environmental<\/strong><\/td> | Changes to infrastructure and external systems<\/td> | Database migrations, vendor APIs, hosting platforms<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n | Component Roles: What, How, Where, With What<\/h2>\n\n\n\nVBD assigns each volatility axis to a dedicated component role. The mental model is four questions: what<\/strong> does the system do, how<\/strong> does it do it, where<\/strong> does data live, and with what<\/strong> shared capabilities. No single role contains all change. The four roles working together localize change across every axis.<\/p>\n\n\n\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>\n\n\n\n Managers coordinate operation flow and encapsulate high-level business orchestration. They represent business intent and workflow coordination. A Manager sequences steps such as validation, pricing, fulfillment, and confirmation without embedding the business rules that perform those steps. Managers should not implement business rules, perform data aggregation, or contain persistence logic. Their responsibility is to express what the system is trying to accomplish, not how it is achieved.<\/p>\n\n\n\n Engines execute business rules, transformations, and computationally intensive operations. They encapsulate the logic most likely to change due to policy shifts, experimentation, or optimization. Engines may persist data when appropriate \u2014 they are not required to delegate all data access to Resource Accessors. They are invoked by Managers and remain unaware of the broader execution context.<\/p>\n\n\n\n Resource 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. Their job is translation: convert a domain request into an external call, convert the response back. They must not apply business rules or make policy decisions.<\/p>\n\n\n\n Utilities encapsulate cross-cutting concerns that apply broadly and evolve independently of business workflows. Logging, monitoring, error classification, feature flags, security primitives. They are orthogonal to core behavior and remain free of domain-specific knowledge.<\/p>\n\n\n\n The communication rules enforce clean volatility boundaries. It is the coordination between roles that captures volatility, not individual roles in isolation. The principle: state flows downward, results propagate upward, horizontal coordination is prohibited.<\/strong><\/p>\n\n\n\n One aspect of VBD that is often undervalued is the explicit separation of business logic into two distinct concerns: orchestration<\/strong> (what happens next) and execution<\/strong> (how to do it). When orchestration and execution are interwoven within the same unit, they become change-coupled. A modification to workflow sequencing forces changes in business rule implementation. By separating them into Managers and Engines respectively, architectures absorb these changes independently, allowing workflows and business rules to evolve at different rates.<\/p>\n\n\n\n Interface and implementation do not have to live together from the start. Begin simple \u2014 a component can present its interface and contain its implementation in the same deployable unit. As deployment needs evolve, separate them. The architecture supports this progression because the communication rules already define the contracts. Premature physical separation adds complexity without benefit; the structural boundaries exist regardless of how the code is packaged.<\/p>\n\n\n\n VBD validates structural decisions by tracing core use cases through the component hierarchy. If a scenario can be traced through Manager, Engine, and Accessor without bypassing communication rules, the boundaries are correct. If a scenario requires an Engine to call another Engine, or an Accessor to apply business logic, the boundaries need adjustment. If a core use case requires bypassing defined communication rules, the architecture should be reconsidered.<\/p>\n\n\n\n Volatility analysis is not a one-time activity. As systems evolve, new volatility axes emerge and existing assumptions may become invalid. Maintain architectural integrity by monitoring changes in requirements, infrastructure, and usage patterns; conducting periodic architectural reviews; updating volatility classifications and component boundaries; and communicating architectural changes to all stakeholders.<\/p>\n\n\n\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\n\n\n |