Clean Architecture, Hexagonal Architecture, and Onion Architecture are frequently cited together as 'the same idea with different diagrams.' At the level of what each one actually prescribes, what is Clean Architecture's specific structure, and what's genuinely different about it versus just being a relabeling of the other two?

## One family, three diagrams Clean Architecture (Robert C. Martin, 2012 blog post / 2017 book), Hexagonal Architecture (Alistair Cockburn, 2005, also called Ports and Adapters), and Onion Architecture (Jeffrey Palermo, 2008) are usually grouped together because they share the same root goal: keep the code that encodes business rules free of dependencies on databases, UI, and frameworks, and arrange dependencies so they point toward that business logic rather than away from it. | Style | Originator | When | |---|---|---| | Clean Architecture | Robert C. Martin | 2012 blog post / 2017 book | | Hexagonal Architecture (Ports and Adapters) | Alistair Cockburn | 2005 | | Onion Architecture | Jeffrey Palermo | 2008 | All three postdate one another by only a few years and clearly influenced each other; none of them is 'more correct' than the others - they're different diagrams and vocabularies drawn over largely the same underlying discipline, sometimes generically called dependency inversion or 'the business logic doesn't know about the outside world.' ## What is specific to Clean Architecture What's specific to Clean Architecture is the particular four-ring breakdown and its naming: - **Entities** (enterprise-wide business rules); - **Use Cases** (application-specific orchestration); - **Interface Adapters** (controllers, presenters, gateways - the translation layer); - **Frameworks & Drivers** (the actual technology). Notably, Clean Architecture is the one of the three that insists on separating Entities from Use Cases as two distinct rings, rather than treating 'the domain' as a single undifferentiated core - it explicitly calls out that a business rule true across the whole enterprise (an entity invariant) is a different kind of thing from a rule specific to one application's workflow (a use case), and gives each its own ring with its own dependency direction toward the other. ## The Dependency Rule as one sentence Clean Architecture also gives the governing principle an explicit, named form - the **Dependency Rule** - stated as a single sentence (source code dependencies can only point inwards) that's easy to communicate, teach, and check for in a code review or an architecture test, which is arguably why 'Clean Architecture' is the label that ended up sticking in day-to-day industry conversation even when a codebase's actual origin was Cockburn's or Palermo's writing. It pairs that rule with companion, complementary ideas Martin bundled into the same body of work: - **screaming architecture** - organize by use case, not delivery mechanism; - the notion that the frameworks/drivers ring is meant to be treated as a detail, deferred as late as possible in a project's life. ## Is the difference genuine? Whether the difference between the three is 'genuine' depends on what you're asking. At the level of runtime behavior and dependency direction, a well-built system following any of the three looks nearly identical from the outside: a core with zero framework imports, explicit interfaces at its boundary, and adapters plugged in from the edge - which is why it's fair, in an interview, to say the substantive overlap is large. At the level of vocabulary and prescribed structure, they do genuinely differ: how many named layers there are, whether 'use case' gets its own ring separate from 'domain,' and what each ring's boundary artifacts are called are all specific choices Clean Architecture makes that the other two frame differently. A team can honestly say they're using 'Hexagonal Architecture' while having exactly the ring count and naming Clean Architecture prescribes, because the diagrams are describing overlapping structures with different emphasis, not mutually exclusive rule sets. ## The failure mode that actually matters The failure mode in practice isn't usually picking the 'wrong' one of the three - it's spending review or design-doc time litigating which diagram a given codebase most resembles, as if the label itself carried enforceable rules, rather than checking the one thing that actually matters across all three: does a dependency-direction check (manual review, or an automated tool like ArchUnit or dependency-cruiser) show the core has zero imports from a database driver, a web framework, or a UI library? A codebase that passes that check is doing 'the thing' regardless of which of the three names is on the whiteboard; a codebase that fails it isn't rescued by having the right diagram in a wiki page. ## A worked example A concrete example: two teams at the same company independently build services with a core domain package containing zero framework imports, an application package holding use-case-style orchestration classes, and an adapters package with the web-framework controllers and ORM repositories. - One team calls their design 'Hexagonal' because they think in terms of an inbound port (the use-case interface) and outbound ports (repository interfaces) with adapters plugged into both. - The other calls the identical shape 'Clean Architecture' because they think in terms of Martin's four named rings. A reviewer checking only for the Dependency Rule - do imports point inward - would find both codebases equally compliant, which is the practical takeaway: the family of ideas is what earns the architectural benefit, not the specific label chosen for the whiteboard.