Methodologies

The Methodologies

Harmonic Design synthesizes four frameworks into a unified whole. Each retains its full set of rules, role definitions, and validation approach — but HD governs how they connect, how they reinforce each other, and how structural decisions at one layer propagate through all others.


Volatility-Based Decomposition (VBD)

The backend structural model. Organize components around anticipated change, not current functionality.

VBD identifies four volatility axes — functional, non-functional, cross-cutting, and environmental — and assigns each to a dedicated component role. Managers coordinate workflow. Engines execute business rules. Resource Accessors isolate external dependencies. Utilities handle cross-cutting concerns. Communication rules enforce clean boundaries: state flows downward, results propagate upward, horizontal coordination is prohibited.

Read the full methodology →

Experience-Based Decomposition (EBD)

The interface structural model. Structure interfaces around human intent, not screens or components.

EBD establishes three behavioral tiers — Experiences (complete user journeys), Flows (goal-directed sequences), and Interactions (atomic user actions) — plus shared Utilities. The same volatility axes apply: non-functional change is isolated in the Experience, functional change in Flows and Interactions, cross-cutting in Utilities, and environmental concerns are handled at the Experience boundary. The Experience is the exclusive communicator with the backend.

Read the full methodology →

Boundary-Driven Testing (BDT)

The test strategy map. Testing difficulty is architectural evidence, not a testing problem.

BDT maps the test spiral to the structural models defined by VBD and EBD. Each tier has a natural test profile: Engines and Flows at unit scope, seams between tiers at integration scope, complete journeys at E2E scope. Mock placement follows from structural position — you mock at boundaries because boundaries are the architecturally significant seams.

Read the full methodology →

Project Design (PD)

The project planning model. You cannot estimate what you have not designed.

Project Design derives the project plan from the architectural decomposition. Components become work packages. Dependencies become the project network. The critical path determines duration. Float analysis quantifies risk. The result is not one plan but a set of viable options with quantified trade-offs — enabling rational decision-making rather than guesswork.

Read the full methodology →


How They Connect

The four frameworks are structurally isomorphic. The same volatility axes drive decomposition at every layer. The same communication rules apply. The same validation mechanism — trace a core scenario through the hierarchy — works in all four. A structural insight at one layer informs all layers simultaneously.

A business rule changes, a new workflow is added, or orchestration logic shifts — absorbed by Manager and Engine, leaving infrastructure and shared concerns untouched.
An estimate was wrong or new work has been added to the schedule. Nothing in the code changes — the architecture is intact. You adjust the work packages, recalculate the critical path, and re-evaluate float. The same structural decomposition that produced the original plan still governs the updated one.
Non-functional volatility covers the stability qualities: performance, scalability, reliability, availability, extensibility, maintainability, security, and observability. Most are addressed outside the application — scalability through infrastructure, security and observability through cross-cutting Utilities. Extensibility requires a one-time structural investment: expose configuration points, support injection where hardcoded behaviour exists. Once done, new behaviours arrive as configuration, not code. The design itself is the primary answer to most non-functional concerns — which is why a well-decomposed system rarely generates ongoing churn from them.
An external API changes, a database is migrated, a vendor is replaced — absorbed entirely by the Resource Accessor. Nothing above it changes.
Logging standards change, auth conventions shift, observability tooling is replaced — absorbed by Utilities, which are consumed by all tiers but owned by none.
VBD Manager
EBD Experience
BDT Unit · Integration E2E · UAT
Project Design Integration Milestone
VBD Engine
EBD Flow · Interaction
BDT Unit · Integration
Project Design Core Work Package
VBD Resource Accessor
EBD
BDT Unit translation only
Project Design Boundary Work Package
VBD Utility
EBD Utility
BDT Unit
Project Design Shared Infrastructure
Stay in the loop.