Software teams rarely suffer from a lack of frameworks. They suffer from frameworks that do not speak to each other.<\/p>\n\n\n\n
A team might apply Domain-Driven Design to their backend, atomic design to their component library, coverage targets to their test strategy, and agile ceremonies to their project management. Each framework is locally sensible. Together, they produce a system where the backend’s bounded contexts do not correspond to the frontend’s component hierarchy, the test strategy was written by convention rather than derived from the architecture, and the project plan was estimated from user stories rather than from the system’s structural dependencies.<\/p>\n\n\n\n
When something changes, the engineer must simultaneously reason in four different structural languages. The seams between frameworks become the places where coupling hides and where plans fail.<\/p>\n\n\n\n
Harmonic Design is a unified software engineering framework built on a single organizing principle:<\/p>\n\n\n\n
Software should be organized by how it changes, not by what it currently does.<\/strong><\/p><\/blockquote>\n\n\n\n
This isn’t a new idea in isolation \u2014 it’s the underlying insight of four independently developed frameworks that we’ve been building and refining over the past several years. What’s new is the recognition that they all ask the same fundamental question, and that applying that question coherently across every layer of a system produces structural properties that none of the frameworks achieves alone.<\/p>\n\n\n\n
The Four Pillars<\/h2>\n\n\n\n
- Volatility-Based Decomposition (VBD)<\/strong> \u2014 Backend system architecture organized around axes of anticipated change. Components are classified as Managers (orchestration), Engines (business logic), Resource Accessors (external boundaries), or Utilities (cross-cutting concerns). Each role isolates a distinct axis of volatility.<\/li>
- Experience-Based Decomposition (EBD)<\/strong> \u2014 Interface architecture built on the same principle. Experiences, Flows, Interactions, and Utilities \u2014 the same four volatility axes, applied to the interface layer \u2014 because interface change follows the same four axes, just with different drivers.<\/li>
- Boundary-Driven Testing (BDT)<\/strong> \u2014 Test strategy derived from the architecture, not written by convention. The test profile for each component role is determined by its structural position: what it orchestrates, what it executes, and where its boundaries lie. Testing difficulty is diagnostic \u2014 if a component is hard to test, its boundaries are in the wrong place.<\/li>
- Project Design (PD)<\/strong> \u2014 Project planning derived from the same structural map. Work packages correspond to components. Dependencies in the project network mirror dependencies in the architecture. Estimation difficulty signals the same class of problem as testing difficulty.<\/li><\/ul>\n\n\n\n
The Structural Isomorphism<\/h2>\n\n\n\n
The central claim of Harmonic Design is precise: the four pillars are structurally isomorphic. The same four roles appear at every layer, carrying the same responsibilities, the same communication rules, and the same test and planning characteristics \u2014 because they isolate the same axes of anticipated change.<\/p>\n\n\n\n