Evolution of Backend Architecture: N‑Layered, DDD, Hexagonal, Onion and Clean Architecture

The author, a self‑described senior architect, introduces the need for developers to understand popular backend architectural patterns such as N‑Layered, DDD, Hexagonal, Onion, and Clean Architecture, emphasizing that grasping their history, purpose, and differences can set one apart from peers.

In the early days, developers only needed to know GoF design patterns; as applications grew more complex, the separation of UI and business logic became essential, leading to various MVC‑like patterns. However, misconceptions about the term “Model” (often confused with DTOs) persisted, especially in the Microsoft ecosystem.

Martin Fowler’s 2002 book on enterprise application architecture introduced the N‑Layered approach, advocating grouping related code into distinct layers (UI, Business Logic, Data Access) without strict rules on naming or number of layers.

In 2003, Eric Evans published Domain‑Driven Design , promoting the isolation of domain logic and suggesting a layered structure: Presentation, Application, Domain, and Infrastructure. This added a dedicated Application layer for use‑cases and emphasized keeping the domain model free of infrastructure concerns.

The Hexagonal (Ports and Adapters) architecture, popularized by Alistair Cockburn in 2005, further refined the idea by separating core business logic (the “Core”) from external concerns via ports (interfaces) and adapters (implementations). This enables independent deployment of components and easier swapping of infrastructure pieces.

Onion architecture (2008) built on these ideas, placing the domain at the center, surrounded by application services, and then infrastructure and UI layers, all respecting the rule that outer layers may only depend on inner layers.

Clean Architecture (2012) by Robert C. Martin combined the previous concepts, adding an outermost framework layer for external tools while keeping the domain and use‑case layers pure. It stresses that dependencies must point inward and that the core should be independent of any external technology.

All these styles share the same goal: separating responsibilities to improve maintainability, testability, and flexibility. The article also notes that the exact number of layers is flexible—three layers often suffice—but the key is a clear, unidirectional dependency graph.

Example code illustrating a controller that invokes a use‑case in a Clean/Hexagonal setup:

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

Finally, the author encourages readers to experiment with these architectures in real projects, to question layer boundaries, and to continuously refine their designs.