One Structure. Every Layer.
Harmonic Design is a unified software engineering framework. It applies a single organizing principle — isolate change along its natural axes — consistently across backend architecture, interface architecture, test strategy, and project planning.
Every long-lived software system has a backend that must evolve, an interface that must evolve, tests that must survive both kinds of evolution, and a project plan that must anticipate, sequence, and resource all three. These concerns are typically governed by separate frameworks and separate mental models. Harmonic Design unifies them under a single structural discipline.
Methodologies
Four methodologies, one structural principle. Each governs a different architectural concern. All share the same decomposition logic.
Volatility-Based Decomposition
Backend systems organized around anticipated change, not current functionality. Components that change for the same reason belong together; components that change for different reasons belong apart.
Experience-Based Decomposition
Interface architecture structured around human intent, not screens. Experiences represent complete user journeys. Flows own goal-directed sequences. Interactions are atomic.
Boundary-Driven Testing
Testing difficulty is architectural evidence. The test spiral is a structural map, not a testing methodology. Correct boundaries produce testable systems; incorrect boundaries produce test friction.
Project Design
Project plans derived from architecture. Components become work packages. Dependencies become the project network. Estimation follows from structural analysis, not intuition.
Structural Isomorphism
The central claim: the role taxonomy of VBD, the tier taxonomy of EBD, the test scope taxonomy of BDT, and the work package classification of Project Design map onto each other exactly. They are four readings of the same underlying structural map.
| Tier | VBD | EBD | BDT | Project Design |
|---|---|---|---|---|
| Orchestration | Manager | Experience | Integration / E2E | Integration Milestone |
| Execution | Engine | Flow / Interaction | Unit | Core Work Package |
| External Boundary | Resource Accessor | API Accessor | Unit (translation) | Boundary Work Package |
| Cross-Cutting | Utility | Utility | Unit | Shared Infrastructure |
A change in business logic touches one Engine, one Flow, one set of unit tests, and one work package — structurally bounded, predictably scoped, estimable from the architecture.
Read the framework. Apply the structure.
Start with the methodology that matches your current concern, or read the white papers for the theoretical foundation.