From N‑Layered to Clean Architecture: Tracing the Evolution of Backend Design

2002 – N‑Layered Architecture

Martin Fowler introduced the idea of grouping related code into separate layers—UI, Business Logic (BLL), and Data Access (DAL)—so that each outer layer only references the inner one. This hierarchical dependency reduces duplication and makes the system easier to reason about. In a typical three‑layer project the UI calls the BLL, which in turn calls the DAL via interfaces.

2003 – Domain‑Driven Design (DDD)

Eric Evans kept the inward‑only dependency rule but added an Application Layer that coordinates use‑cases and moves heavy controller logic out of the UI. He renamed the layers to Presentation, Application, Domain, and Infrastructure. The Domain layer contains rich entities (behaviour‑rich models) rather than anemic data transfer objects. Lower‑level modules may call higher‑level ones via callbacks or the Observer pattern, preserving the overall direction of dependencies.

2005 – Hexagonal (Ports & Adapters) Architecture

Alistair Cockburn reframed the architecture as a hexagon. The core business logic lives inside and depends only on abstract ports (interfaces). Concrete adapters (UI, database, email, etc.) implement those ports. Because the core never references an adapter, any adapter can be swapped without touching the domain logic.

2008 – Onion Architecture

Jeffrey Palermo extended the hexagonal ideas by enforcing that the innermost Domain layer never depends on any outer layer. The Infrastructure and Presentation layers may depend on the Application layer, but never the reverse. The composition root (e.g., a Main() function) lives in the Presentation layer and wires all dependencies, resulting in a dependency graph that mirrors the N‑layered diagram with arrows pointing inward.

2012 – Clean Architecture

Robert C. Martin (Uncle Bob) refined the previous models by adding an outermost Framework layer that contains external tools (web frameworks, databases, etc.). Inside, the Use‑Case (or Interactor) layer implements application‑specific business rules, while the Domain layer holds pure entities. Controllers act as input ports, presenters as output ports, and the dependency direction remains inward, making the core reusable in any environment.

Practical Walk‑through

To apply these ideas, developers should:

Define clear layer boundaries (UI/Presentation, Application/Use‑Cases, Domain, Infrastructure).

Expose each layer through interfaces (ports) and depend only on abstractions.

Keep the dependency direction strictly inward: outer layers reference inner ones, never the reverse.

Prefer logical separation via folders when physical project separation adds unnecessary complexity.

When swapping a peripheral concern (e.g., UI framework or database), replace only the corresponding adapter without touching the core.

A minimal ASP.NET Core controller that follows Clean Architecture illustrates the pattern:

class OrderController : ControllerBase, IInputPort, IOutputPort {
    [HttpGet]
    public IActionResult Get(int id) {
        _getOrderUseCase.Execute(id);
        return DisplayOutputPortResult();
    }
}

Key References

Martin Fowler, Enterprise Application Architecture Patterns (2002) – defines N‑layered rules.

Eric Evans, Domain‑Driven Design: Tackling Complexity in the Heart of Software (2003) – introduces Application and Domain layers.

Alistair Cockburn, "Hexagonal Architecture" (2005) – ports & adapters concept.

Jeffrey Palermo, "Onion Architecture" (2008) – strict inward dependency.

Robert C. Martin, "Clean Architecture" (2012) – adds Framework layer and Use‑Case interactors.

Medium article documenting the evolution: https://medium.com/@iamprovidence/from-3-layered-to-ddd-architecture-in-one-step-f3de204bec2e

The evolution from simple N‑layered separation to Clean Architecture shows a steady move toward stricter dependency control, richer domain models, and clearer separation of concerns, resulting in codebases that are more maintainable, testable, and adaptable to change.