From Traditional Layered Architecture to Hexagonal and Clean Architecture: Principles, Problems, and Dependency Inversion

The article begins by stating the core principle of layered architecture: each layer may only couple with the layer directly below it, distinguishing between strict and loose layering.

It presents a typical DDD traditional layered diagram (image) and describes the responsibilities of each layer:

User Interface Layer handles user requests and presentation.

Application Layer implements use cases and business processes; an example method is shown:

public void cancelOrder(Long orderId) {
    Order order = orderRepository.findById(orderId);
    // domain logic
    order.cancel();
    orderRepository.save(order);
}

Domain Layer contains core business logic and domain models, distinct from the application flow.

Infrastructure Layer provides technical services such as data persistence.

The article then discusses problems of the traditional layered architecture, especially where to place repository implementations, noting that placing them in the infrastructure layer creates an upward dependency that violates the layering rule, while placing them in the domain or application layers couples those layers to persistence details.

It proposes using the Dependency Inversion Principle (DIP) to resolve this, quoting the principle: "High‑level modules should not depend on low‑level modules; both should depend on abstractions. Abstractions should not depend on details; details should depend on abstractions."

Applying DIP, the repository interface resides in the domain layer while its implementation stays in the infrastructure layer, reversing the dependency direction. A revised layered diagram (image) illustrates this change.

The article introduces the Hexagonal Architecture (also known as Ports and Adapters), showing how flattening the layered structure after applying DIP results in a hexagonal shape (image) and describing its benefits: consistent interaction via adapters for HTTP, RPC, MQ, persistence, etc.

It explains why Clean Architecture is not chosen directly, summarizing its principles from Robert C. Martin’s book, emphasizing independence from frameworks, UI, databases, and external agencies, and providing a quoted list of these characteristics.

A Clean Architecture diagram (image) is shown, depicting concentric circles where inner layers are higher‑level and do not depend on outer layers.

In the final summary, the article asserts that both the DIP‑adjusted layered architecture and the hexagonal architecture conform to Clean Architecture’s design philosophy, with hexagonal ports and adapters offering clear boundaries and preventing domain logic leakage.

References are listed for further reading.