How is Clean Architecture different from Hexagonal Architecture?

They share the same fundamental principle — dependencies point inward toward business logic — but Clean Architecture defines a more explicit concentric-circle layering (Entities, Use Cases, Interface Adapters, Frameworks/Drivers) with a named 'Dependency Rule,' while Hexagonal Architecture uses the ports-and-adapters metaphor with fewer prescribed layers.

What is the 'Dependency Rule'?

It states that source code dependencies can only point inward: outer, more volatile layers (frameworks, databases, UI) may depend on inner layers (business rules), but inner layers must never depend on or reference anything from outer layers.

Do I need a specific framework to implement Clean Architecture?

No — it's a language- and framework-agnostic set of principles about dependency direction and layer separation; it has been implemented in many languages including Java, C#, Python, Go, and TypeScript, usually with interfaces defining the boundaries between layers.

Is Clean Architecture worth the extra boilerplate for small projects?

Often not — its strict layering, interfaces, and data-transfer objects between layers add real overhead, and critics argue the tradeoff only pays off for applications that are large, long-lived, or need extensive independent testability of business rules.

Who wrote about Clean Architecture and where?

Robert C. Martin ('Uncle Bob') described it in his 2017 book Clean Architecture: A Craftsman's Guide to Software Structure and Design, building on ideas he and others had discussed in blog posts and talks for years prior.

Programming

Clean Architecture

Coined by Robert C. Martin ("Uncle Bob")

AdvancedConcept5.4K learners

Clean Architecture is a software architecture pattern, described by Robert C. Martin, that organizes code into concentric layers with dependencies pointing strictly inward toward core business rules, keeping frameworks, databases, and UI…

#CleanArchitecture #Programming#Concept#Advanced#HexagonalArchitecture #OnionArchitecture #RepositoryPattern #DependencyInjection #SoftwareDevelopment#Glossary#SkillVeris

Definition

Overview

Clean Architecture was described by Robert C. Martin (widely known as 'Uncle Bob') in his 2017 book Clean Architecture, synthesizing ideas from several earlier architecture patterns — including hexagonal architecture, onion architecture, and DCI (Data, Context, Interaction) — into a single set of guiding principles. The architecture is typically drawn as a set of concentric circles. At the very center sit Entities, representing enterprise-wide business rules and core domain objects. The next ring out holds Use Cases (or Interactors), which encode application-specific business rules and orchestrate the flow of data to and from entities. Outside that is the Interface Adapters layer, which converts data between the format most convenient for use cases/entities and the format most convenient for external agents like databases or the web (this is where controllers, presenters, and gateways live). The outermost ring, Frameworks and Drivers, contains the actual technology choices — the web framework, the database, external APIs, dependency-injection frameworks. The pattern's single governing rule is the Dependency Rule: source code dependencies must point only inward, from outer, more volatile, technology-specific layers toward inner, more stable, business-rule layers. Inner layers must never reference anything from outer layers, including their names or types. Because outer layers depend on abstractions (interfaces) defined by inner layers rather than the other way around, this achieves the Dependency Inversion Principle at an architectural scale: business rules can be compiled, tested, and reasoned about with zero knowledge of which database, web framework, or UI technology the application ultimately uses. The practical benefits mirror hexagonal architecture's: business logic is independently testable without a database or web server running, and technology decisions (which framework, which database) become deferrable and replaceable details rather than foundational constraints baked into the core. Clean Architecture is influential across many language ecosystems and is frequently cited alongside Domain-Driven Design in discussions of how to structure large, long-lived applications, though critics note that its strict layering and heavy use of interfaces/DTOs can introduce significant boilerplate for smaller or simpler applications where the flexibility payoff isn't needed.

Key Concepts

Organizes code into concentric layers: Entities, Use Cases, Interface Adapters, Frameworks/Drivers
Governed by the 'Dependency Rule' — dependencies point strictly inward, never outward
Business rules (Entities, Use Cases) have zero knowledge of databases, frameworks, or UI
Achieves the Dependency Inversion Principle at the architectural level via inward-facing interfaces
Synthesizes ideas from hexagonal architecture, onion architecture, and DCI
Enables testing core business logic without a running database, server, or UI
Treats framework and database choices as replaceable, deferred implementation details
Described by Robert C. Martin in his 2017 book Clean Architecture

Use Cases

Structuring large, long-lived applications expected to evolve significantly over time

Isolating core business rules for fast, dependency-free unit testing

Deferring technology decisions (framework, database) until later in a project's lifecycle

Supporting multiple delivery mechanisms (web, CLI, mobile) over the same core logic

Enterprise applications where business rules must remain stable across framework upgrades

Codebases practicing Domain-Driven Design that need a matching architectural structure

Frequently Asked Questions

From the Blog

Career Growth

How to Build a Standout Tech Resume

Most developer resumes list duties instead of impact. This guide shows how to rewrite every bullet with the impact formula, pass ATS keyword filters, present projects effectively, and design a clean one-page resume that gets interviews.