Should Services Strictly Follow Layered Calls in DDD? Dealing with Interface Pass‑Through

Several architects recently asked whether, under a layered architecture, system calls should also strictly follow the hierarchy, especially when many query‑type functions result in pure pass‑through.

Typical Four‑Layer Architecture

The classic layered model divides an application into four layers, each focusing on its own concerns—an embodiment of the separation‑of‑concerns principle.

Strict layered calls mean a request traverses each layer in order, without cross‑layer access.

From Layered to DDD: The COLA Refinement

In DDD, the four layers evolve into Adapter, Application, Domain, and Infrastructure layers. Their responsibilities are:

Adapter layer : routes and adapts front‑end requests (Web, App) – similar to MVC controllers.

Application layer : gathers input, assembles context, validates parameters, invokes the Domain layer, and may send notifications; it can also bypass the Domain layer to call Infrastructure directly.

Domain layer : encapsulates core business logic, exposing services and entities to the Application layer; it does not depend on any other layer.

Infrastructure layer : handles technical details such as database CRUD, search, file systems, RPC, and acts as a gateway to external dependencies, protecting the Domain layer.

Because the Domain layer is open, the question arises: if many interfaces are merely pass‑through, how should they be handled?

Sinkhole Anti‑Pattern vs. Strict Layer Calls

Martin Fowler describes the “architecture sinkhole” anti‑pattern, where request flow simply passes through layers without leaving any trace—like water flowing down a drain.

Example: the UI layer receives a data request, forwards it to the Business layer, which merely forwards it to the Persistence layer; the Persistence layer executes a simple SQL query and returns the raw data straight back to the UI, with no additional processing.

The term “sinkhole” is a metaphor for a sewage system where each layer drains into the next without retaining anything.

When to Open a Layer

Apply the 80‑20 rule: if more than 20 % of functionality in a layer is pure pass‑through, consider opening that layer. However, opening layers can increase tight coupling, making the project harder to test, maintain, and deploy.

Final Thoughts

The author reflects on the value of domestic certification frameworks for structuring architectural knowledge and draws a parallel to modern AI discussions, emphasizing the need to focus on practical value rather than rigid adherence to any single methodology.