Now that we’ve covered many layering approaches, it is time to combine them into Clean Architecture, also known as Hexagonal Architecture, Onion Architecture, Ports and Adapters, and more. Clean Architecture is an evolution of the layers, a way of organizing the relationships between the layers, yet very similar to what we just built. Instead of presentation, domain, and data (or persistence), Clean Architecture suggests UI, Core, and Infrastructure.As we saw previously, we can design a layer containing abstractions or implementations. When implementations depend only on abstractions, that inverts dependency flow. Clean Architecture emphasizes such layers but with its own guidance about organizing them.We also explored the theoretical concept of breaking layers into smaller ones (or multiple projects), thus creating “fractured layers” that are easier to port and reuse. Clean Architecture leverages that concept at the infrastructure layer level.There are probably as many points of view and variants of this as there are names for it, so I’ll try to be as general as possible while keeping the essence. By doing this, if you are interested in this type of architecture, you can pick a resource and dig deeper into it, following the style you prefer.Let’s take a look at a diagram that resembles what we can find online:
Figure 14.12: A diagram representing the most basic Clean Architecture layout
From a layering diagram-like standpoint, the preceding diagram could look like this:
Figure 14.13: A two-layer view of the previous Clean Architecture diagram
Depending on your chosen method, you can split those layers into multiple other sublayers. One thing that we often see is dividing the Core layer into Entities and Use cases, like this:
Figure 14.14: Widespread Clean Architecture layout diagram
Since people in the tech industry are creative, there are many names for many things, but the concepts remain the same. From a layering diagram-like standpoint, that diagram could look like this:
Figure 14.15: A layer-like view of the previous Clean Architecture diagram
The infrastructure layer is conceptual and can represent multiple projects, such as an infrastructure assembly containing EF Core implementations and a website project representing the web UI. We could also add more projects to the infrastructure layer.The dependency rule of Clean Architecture states that dependencies can only point inward, from the outer layers to the inner layers. This means that abstractions lie inside, and concretions lie outside. Based on the preceding layer-like diagram, inside translates to downward. That means a layer can use any direct or transitive dependencies, which means that infrastructure can depend on use cases and entities.Clean Architecture follows all the principles that we’ve been discussing since the beginning of this book, such as decoupling our implementations using abstractions, dependency inversion, and separation of concerns. These implementations are glued over abstractions using dependency injection (this is not mandatory, but it helps).I’ve always found those circle diagrams a bit confusing, so here is my take on an updated, more linear diagram:
Figure 14.16: A two-layer view of Clean Architecture’s common elements
