Clean Architecture – Follow A Request

How does a request or call proceed through the Clean Architecture?

With the traditional n-tier architecture model, the flow of control through the various tiers is as expected: First, it hits the top-most and user-facing Presentation Tier, then moves onto the business logic and finally calls into the Data Tier. From here, it makes its way back up through all the tiers to the external caller.

It’s less clear, though, how a call would traverse the concentric ‘shells’ of Clean Architecture.

Or is it?

A call coming into the system would traverse to the innermost shell, Entities and then back out again to retrieve data from external systems, say, a database. As the database responds, the call would bounce back along the same path that it came in on. The following diagram outlines (the blue arrows) the execution path taken through a Clean Architecture system.

An external caller, an Actor in UML, initiates the call, i.e. from outside the outermost shell. 

Let’s play through an external request coming into an HTTP API:

1. The web server receives and accepts the HTTP request. Say, our web server is running ASP.NET WebApi. We are in the outermost shell of the Clean Architecture. The request moves through the ASP.NET pipeline, which will route it to the correct controller action.
2. The request has ended up as a call to a controller action method. Here, data that must cross over into the business logic shell will be converted to neutral business logic models. Then the flow of control is further delegated to a business logic workflow or use case.
3. We’ve crossed over into business logic to the Use Case shell. Here a business logic workflow is executed. This workflow will engage the help of Entities, the innermost shell, to fulfil its step-by-step instructions.
4. Suppose the use case must retrieve or alter data from a peripheral system like a database. In that case, it will make a call into the Interface Adapter shell through an interface or other abstraction. The call is moving back into the outer shells. Here we have data access logic that is aware of the specific business contect (e.g. we want to retrieve customer order data) as well as database specifics (e.g. SQL Server).
5. The call continues into the outermost layer, here representing the generic code suitable for all SQL Server databases.
6. The request proceeds outside of our Clean Architecture system and retrieves the data from our SQL Server database.
7. After all this, the flow of execution returns to our system and winds its way back up the same way until the data is returned to the external client, say, via an HTTP response.