{"id":722,"date":"2026-04-17T08:00:00","date_gmt":"2026-04-17T13:00:00","guid":{"rendered":"https:\/\/harmonic-framework.com\/?p=722"},"modified":"2026-04-16T22:33:11","modified_gmt":"2026-04-17T03:33:11","slug":"why-i-built-harmonic-design","status":"publish","type":"post","link":"https:\/\/harmonic-framework.com\/es\/why-i-built-harmonic-design\/","title":{"rendered":"Why I Built Harmonic Design"},"content":{"rendered":"\n

I have worked with agile teams, waterfall teams, hybrid teams, and teams that had simply embraced anarchy. Different processes, different ceremonies, different levels of documentation and discipline. Engineers, project managers, product owners, SMEs, architects – all present, all engaged, all doing their jobs. The methodology varied. The problem did not.<\/p>\n\n\n\n

Every one of them was running the same invisible experiment: four structural frameworks operating simultaneously, none of them designed to talk to each other. A domain model for the backend. A component system for the frontend. A test coverage strategy. A planning model built on user stories, or milestones, or a whiteboard covered in sticky notes. Each framework was chosen deliberately. Each was individually sound. And the system was still a mess.<\/p>\n\n\n\n

Not because the people were careless. Not because the frameworks were wrong. Because the frameworks were designed in isolation, and nobody – not the engineers, not the project managers, not the product owners – had been given a tool to design the seams between them. Agile did not fix it. Waterfall did not fix it. Anarchy, while occasionally entertaining, just removed the pretense that anyone had agreed on boundaries in the first place.<\/p>\n\n\n\n

\"Four\n
Four frameworks. Four teams. Nobody designed the seams.<\/figcaption><\/figure>\n\n\n\n

The Seam Is Where the Damage Lives<\/h2>\n\n\n\n

When a requirement moves from product to architecture to frontend to testing to planning, it crosses four framework boundaries. Each crossing is a translation. Each translation is imperfect. By the time a feature lands in a pull request, the structural relationships that seemed clear in the planning meeting have been quietly reinterpreted at every layer. Nobody is lying. Nobody is being careless. The frameworks just do not share a vocabulary, so each layer reads the same requirement through a different lens and draws different boundaries in response.<\/p>\n\n\n\n

The damage is not visible as a single failure. It accumulates as friction: the backend team draws one boundary around “checkout,” the frontend team draws a different one, the test suite covers a third shape entirely, and the project plan tracks none of them. When something changes – and it always changes – nobody can predict the blast radius. The change touches the backend boundary, which does not correspond to the frontend boundary, which does not correspond to the test boundary. Three teams are affected by a change that looked like one team’s problem.<\/p>\n\n\n\n

flowchart TB\n    CH(["A change arrives"])\n\n    BE["Backend \/ DDD"]\n    FE["Frontend \/ Atomic Design"]\n    TE["Testing \/ Coverage"]\n    PL["Planning \/ Agile"]\n\n    CH --> BE\n    CH --> FE\n    CH --> TE\n    CH --> PL<\/code><\/pre>\n\n\n\n
The most persistent coupling in a system often lives at the framework boundary, not inside any single framework.<\/p><\/blockquote><\/figure>\n\n\n\n
Why “Use Better Frameworks” Doesn’t Fix It<\/h2>\n\n\n\n
The instinct when a team is struggling structurally is to apply the existing frameworks more rigorously. Better DDD. Stricter atomic design. More disciplined testing. Tighter agile ceremonies. Clearer requirements from the product owner. More detailed specs from the SMEs. More frequent check-ins from the project manager. I have seen teams do all of this – everyone working harder, everyone communicating more – and still produce systems where nobody could confidently predict the impact of a change.<\/p>\n\n\n\n
Rigour within a framework does not buy you coherence across frameworks. You can have a perfectly modelled domain on the backend, a beautifully structured component library on the frontend, and comprehensive test coverage – and still have a planning model that cannot tell you which components are affected by a domain change, because the domain model and the component model were built on different axes and never agreed on where boundaries go.<\/p>\n\n\n\n
The problem is not the quality of the frameworks. It is that the frameworks were designed to answer different questions. DDD asks: what are the bounded concepts in this business domain and how do they relate? Atomic design asks: what is the smallest reusable unit, and how do elements compose into larger structures? A coverage strategy asks: what execution paths need to be exercised, and at what granularity? An agile planning model asks: what value does this deliver to the user, and how do we sequence it? These are all legitimate questions. They are the right questions for the problems each framework was built to solve. None of them is the same question. And none of the boundaries they produce correspond to the others – because none of them asked what causes this unit to change.<\/p>\n\n\n\n
\"A
Every methodology produces the same struggle – until the decomposition principle is shared.<\/figcaption><\/figure>\n\n\n\n
The Question None of Them Ask<\/h2>\n\n\n\n
There is one question that, if every layer answered it, would produce corresponding structure across all of them: what forces this to change?<\/strong><\/p>\n\n\n\n
Not what does this do. Not what does this look like. Not what value does this deliver. What forces it to change – what external pressure, what business rule, what user behaviour, what integration dependency – makes this unit of code need to be different tomorrow than it is today?<\/p>\n\n\n\n
When the backend answers that question, it produces components with stable interfaces and isolated volatility. Business logic lives in one place. External dependencies live in another. Workflow coordination lives in a third. The boundary between them is not a naming convention – it is a change axis. Things that change for the same reason belong together. Things that change for different reasons belong apart.<\/p>\n\n\n\n
When the frontend answers the same question, it produces the same structure at the interface layer. The components that change when the design system changes are different from the components that change when the business flow changes, which are different from the components that change when the underlying data contract changes. Each tier is stable against a different category of change. The structure is not identical to the backend – the concerns are different – but it is corresponding<\/em>. The same vocabulary applies. A change in one layer predicts the shape of the change in the others.<\/p>\n\n\n\n
When testing answers the same question, test type follows naturally from component role. A component that encapsulates pure business logic – one that changes only when the business rules change – is tested in isolation, with no infrastructure, no integration, no external dependencies. A component that coordinates workflow is tested at integration points, because its value is the orchestration, not the logic. The test suite becomes a structural map of the system. Testing difficulty is not a testing problem. It is an architectural signal.<\/p>\n\n\n\n
When planning answers the same question, the work breakdown structure falls out of the architecture. Components with no upstream dependencies can begin on day one. Components that coordinate between others are integration milestones. The critical path is not estimated by intuition – it is read off the dependency graph. An estimate that cannot be grounded in a component boundary is a signal that the boundary is wrong, not that the estimator needs to try harder.<\/p>\n\n\n\n
What Harmonic Design Is<\/h2>\n\n\n\n
Harmonic Design is the application of a single decomposition principle – volatility, the axis of anticipated change – across every layer of a software system. Four disciplines, one question.<\/p>\n\n\n\n
Volatility-Based Decomposition<\/strong> applies it to backend services and systems. Components are classified by what forces them to change. Managers orchestrate – the stable What, sequencing workflow without embedding business rules. Engines execute – the volatile How, implementing the business rules that change most frequently. Resource Accessors translate – the Where, isolating external systems and environmental dependencies from the domain model. Utilities provide the With What – cross-cutting concerns like logging, security, and observability available to all roles without owning any domain logic. Non-functional volatility, such as performance and scalability, is not localized to a single role; it is addressed across the architecture. A change in pricing logic lands in the PricingEngine. A change in order placement flow lands in the PlaceOrderManager. Neither touches the other.<\/p>\n\n\n\n
Experience-Based Decomposition<\/strong> applies the same volatility analysis to frontend interfaces. Three tiers, each absorbing a different kind of change. Experiences own the complete user journey – the full arc from initiation to fulfillment, accumulated state across all steps, and the only tier that communicates with the backend. Flows own goal-directed sequences within a journey – one Flow, one discrete outcome, no knowledge of sibling Flows. Interactions are atomic user actions, the surface users actually touch, with no awareness of the flow they live in. Utilities handle cross-cutting concerns – locale, theming, accessibility, observability. Functional changes ripple through all three tiers. Environmental changes – a new platform, a new runtime – are absorbed by Experiences. Cross-cutting changes are absorbed by Utilities.<\/p>\n\n\n\n
Boundary-Driven Testing<\/strong> derives test strategy from architectural role. The boundaries that VBD and EBD place in the system are exactly the boundaries where tests belong. Engines mock their Resource Accessors – the boundary directly below them, nothing else. Managers mock their Engines and Resource Accessors – every dependency below them, nothing above. The rule is: mock at the boundary below the component under test, not inside it. The test suite is not a separate concern bolted onto the architecture – it is the architecture made executable.<\/p>\n\n\n\n
Project Design<\/strong> derives the project plan from the architecture. The component graph is the dependency graph is the project network. Work packages come from components. Schedule dependencies come from architectural dependencies. Float is computed from the longest chain, not estimated by feel. When a new requirement arrives, you can compute whether it extends the critical path before a single line is written.<\/p>\n\n\n\n
flowchart TB\n    Q(["What forces this to change?"])\n\n    VBD["VBD\\nBackend"]\n    EBD["EBD\\nFrontend"]\n    BDT["BDT\\nTesting"]\n    PD["Project Design\\nPlanning"]\n\n    Q --> VBD & EBD & BDT & PD<\/code><\/pre>\n\n\n\n
One question. Four disciplines. The seams between them are not translation boundaries – they are the same structure, expressed at a different layer.<\/p><\/blockquote><\/figure>\n\n\n\n
Why This Matters in Practice<\/h2>\n\n\n\n
When a team builds with Harmonic Design, a few things become possible that were not possible before. A product manager can describe a change and an architect can immediately identify which components it touches – not by memory or experience, but by structural reasoning. A developer can estimate a work package with confidence because the scope is defined by the component boundary, not by the story description. A test failure points to a specific layer of the architecture rather than somewhere in the system. A schedule slip on one work package tells you exactly which downstream packages are affected and which are not.<\/p>\n\n\n\n
None of this is magic. It is what falls out naturally when the same decomposition principle is applied consistently at every layer. The frameworks talk to each other because they are all asking the same question and using the answer to draw their boundaries.<\/p>\n\n\n\n
That is what was missing. That is what Harmonic Design is.<\/p>\n\n\n\n
Each discipline has been covered in depth in this series. VBD in 10 Minutes<\/a> shows what this looks like for backend services – the four component roles, the communication rules, the before-and-after. EBD in 10 Minutes<\/a> applies the same analysis to frontend interfaces. BDT in 10 Minutes<\/a> derives test strategy from architectural role. Project Design in 10 Minutes<\/a> shows how the architecture becomes the project plan. Each post is self-contained. Read any one of them and you will see the same vocabulary, the same structural question, applied to a different layer.<\/p>\n\n\n\n
\"Four\n
One decomposition principle. Every layer speaks the same language.<\/figcaption><\/figure>\n\n\n\n
The whitepapers are available on the whitepapers page<\/a>. If you want to apply the framework immediately, start with VBD – apply it to one component in your current system and let the friction tell you where your boundaries are misplaced.<\/p>\n","protected":false},"excerpt":{"rendered":"
I have worked with agile teams, waterfall teams, hybrid teams, and teams that had simply embraced anarchy. Different processes, different ceremonies, different levels of documentation and discipline. Engineers, project managers, product owners, SMEs, architects – all present, all engaged, all doing their jobs. The methodology varied. The problem did not. Every one of them was … Read more<\/a><\/p>","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_uag_custom_page_level_css":"","footnotes":""},"categories":[16],"tags":[],"methodology":[],"class_list":["post-722","post","type-post","status-publish","format-standard","hentry","category-foundation"],"uagb_featured_image_src":{"full":false,"thumbnail":false,"medium":false,"medium_large":false,"large":false,"1536x1536":false,"2048x2048":false,"trp-custom-language-flag":false,"post-thumbnail":false,"hf-card":false,"hf-hero":false},"uagb_author_info":{"display_name":"William Christopher Anderson","author_link":"https:\/\/harmonic-framework.com\/es\/author\/admin\/"},"uagb_comment_info":0,"uagb_excerpt":"I have worked with agile teams, waterfall teams, hybrid teams, and teams that had simply embraced anarchy. Different processes, different ceremonies, different levels of documentation and discipline. Engineers, project managers, product owners, SMEs, architects – all present, all engaged, all doing their jobs. The methodology varied. The problem did not. Every one of them was…","_links":{"self":[{"href":"https:\/\/harmonic-framework.com\/es\/wp-json\/wp\/v2\/posts\/722","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/harmonic-framework.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/harmonic-framework.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/harmonic-framework.com\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/harmonic-framework.com\/es\/wp-json\/wp\/v2\/comments?post=722"}],"version-history":[{"count":12,"href":"https:\/\/harmonic-framework.com\/es\/wp-json\/wp\/v2\/posts\/722\/revisions"}],"predecessor-version":[{"id":735,"href":"https:\/\/harmonic-framework.com\/es\/wp-json\/wp\/v2\/posts\/722\/revisions\/735"}],"wp:attachment":[{"href":"https:\/\/harmonic-framework.com\/es\/wp-json\/wp\/v2\/media?parent=722"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/harmonic-framework.com\/es\/wp-json\/wp\/v2\/categories?post=722"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/harmonic-framework.com\/es\/wp-json\/wp\/v2\/tags?post=722"},{"taxonomy":"methodology","embeddable":true,"href":"https:\/\/harmonic-framework.com\/es\/wp-json\/wp\/v2\/methodology?post=722"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}