Clean Architecture IS about Vertical Slicing, actually!

the nature of the clean architecture is the separation of technical concerns using layers which causes low cohesion within a feature and high coupling between features so in order to reduce the overall complexity of a code base we should rather favor the vertical slice architecture which focuses on the exact opposite right well no I cannot agree to that let me explain let's start with summarizing how many developers seem to see the clean architecture the clean architecture is often described as a layout architecture which emphasizes the separation of technical concerns the dependency rule of the clean architecture emphasizes the independence of the domain model and the application logic from technical details like IO and external Frameworks this perception has led to various articles YouTube videos and even project templates on GitHub which suggest to structure your projects according to these layers A quite common template suggests to use the following four projects domain application infrastructure and UI or web API often these templates then recommend to use additional folders to structure the code base further by technical categories like interfaces validators and commands and these articles videos and templates in turn have resulted in other articles and videos which raise major concerns against this kind of project setup these concerns can be grouped into three categories such a project setup causes the code of a feature spread across the entire code base which makes it harder to identify which code belongs to a feature and also requires navigating the entire code base to find and modify the pieces of a single feature such a project setup also causes high coupling between features due to code being shared by kind like product service and products repository and finally such a project setup also causes unnecessary complexity due to unnecessary abstractions even if just a few lines of code would be needed to get the job done and guess what I would even agree that these are severe concerns when finding such effects in a code base to address these concerns usually then the vertical slice architecture is recommended so what is the vertical slice architecture there are various resources describing architectures based on vertical slicing but for this video I want to focus on how Jimmy poga describes the vertical slice architecture in a stock at NDC conferences the first key aspect of the vertical slice architecture is that the code is primarily organized by features that means the top level folders and projects are named according to the high-level functionalities and subfolders are used to break down these functionalities further into smaller features the second key aspect of the vertical slice architecture is that these feature folders should be as independent as possible from each other commonly shared code is only factored out if this code should behave exactly the same for all the features and will also change at exactly the same time for all the features inside each feature folder separation of concerns is only introduced if there is a a benefit if the job can be done with just a few lines of Link You Against The Entity framework core DB context then that's exactly what should be coded how concerns are finally separated is not defined by this architecture so the design can vary from feature to feature the third key aspect of the vertical slice architecture is to describe a feature as a request which is handled by a Handler which returns a single response hereby the Handler is a black box it contains everything needed to fulfill the request including logic and IO from the overall architecture as well as from testing perspective it is not relevant how the internals of the Black Box are organized Jimmy Bogart factored out the common infrastructure of this pattern and released it as the famous.net open source Library mediator if you want to know how to use the mediator library in the clean architecture without marrying it then check out this video in summary the vertical slice architecture aims to maximize cohesion within each slice and it aims to minimize coupling between the slices Additionally the vertical slice architecture doesn't enforce Global separation of technical concerns and guess what I would also agree to the benefits of these concepts for every code base having more than one bigger feature so then facts are clear right the vertical slice architecture offers clear benefits over the clean architecture isn't it well the problem I have with this conclusion is that from my perspective defining the clean architecture as a simple layout architecture is a misconception and here's why the idea that a clean architecture causes the code base of a feature to be spread across the entire code base probably has its origin in the famous circle diagram which obviously shows technical layers but if we look at the history how the clean architecture was developed by uncle pop we see that before the book was published he published this post in 2012 but almost one year earlier he had published this article about the screaming architecture where he emphasizes that a code base should be organized at least on the top level according to Features so that one can clearly identify what the software system is about it clearly says a good architecture emphasizes the use cases and decouples them from peripheral concerns and he also writes your architecture Should Tell the readers about the system not about the Frameworks you used in your system now let's have a look at the table of contents of Uncle Bob's book clean architecture chapter 16 Independence talks about decoupling it talks about decoupling from details but it also talks about decoupling use cases Uncle Bob writes at the same time use cases are narrow vertical slices that cut through the horizontal layers of the system in chapter 21 screaming architecture he writes when you look at the top level directory structure do they scream healthcare system or accounting system so he obviously wrote an entire chapter about organizing your code Base According to functionalities and features and only in chapter 22 clean architecture after having talked about vertical slicing he finally talks about technical layers the circles and the dependency rule so in summary even so the clean architecture has a clear focus on separation of the business logic from technical details neither in his blog articles nor in his book Uncle Bob suggests to organize your code base primarily by layers Uncle Bob not only in fact does talk about structuring your code base along features he even talks about these things first now after having sorted that out let's look at the concern that the clean architecture causes coupling between features because layers motivate to have shared application services and shared repositories well one aspect Uncle Bob clearly points out the center of the clean architecture are the entities or the domain model which is not only shared across all features of an application but might even be shared between applications across the Enterprise and of course a shared domain model causes coupling but at the same time it causes consistency consistency of the business rules across features which definitely adds value to the overall system and what about the domain model in the vertical slice architecture Jimmy clearly states that when the code increases in a Handler he would start to push the behavior down into the domain model in this talk he does not explicitly say that the domain model is shared across the handlers but I think we can read between the lines that it actually is in summary both the clean architecture and the vertical slice architecture have the concept of a shared domain model and accept the trade-off it implies between coupling and consistency but what about the feature specific code is the clean architecture suggesting to have entity or topic Centric shared application services like a card service or a product catalog service if we have a closer look at the words used in this diagram we cannot see the word service anywhere but what we do see is the word use case at multiple places so what is a use case in the clean architecture Uncle Bob defines a use case as follows a use case is a description of the way that an automated system is used it specifies the input to be provided by the user the output to be returned to the user and the processing steps involved in producing that output from this definition we can already derive that in the clean architecture a use case also called a use case in the actor contains the log Project Specific to a particular feature and even specific to a particular request in his book clean architecture Uncle Bob talks about the control flow in more detail and he visualizes it like this in this diagram we can see a particular request as passing technical layers to a request specific interactor which creates a request specific response this diagram clearly shows that the basic control flow of the clean architecture consists of feature-specific requests request specific controllers request specific use case interactors which create request specific responses comparing the basic control flow suggested by the clean architecture with the one proposed by the vertical slice architecture we have to assess that both are quite similar in the clean architecture the application logic a use case interactors as well as the overall control flow a feature and request oriented and so are in fact vertically sliced ok but isn't the clean architecture also emphasizing code reuse inside the use case layers taking the table of contents of the book clean architecture as a reference we can say that the clean architecture is based on the solid principles as well as on the component principles Uncle Bob already introduced earlier in agile principles patterns and practices in c-sharp considering just two of these principles the single responsibility principle and the common Rios principle it becomes obvious that the clean architecture has a clear focus on conscious reuse as well emphasizing the awareness of the trade-off between Rios and coupling but the vertical slice architecture Is Not So Different in this Regard in his talk Jimmy initially suggests that in the vertical slice architecture a Handler should contain all the code needed to handle a request and to produce a response but he later admits that this could lead to code duplication which if the code duplication is intentional should be factored out into common code of some appropriate kind so that means both architectures the clean architecture as well as the vertical slice architecture clearly recommend the conscious reuse of code that changes at the same time for the same reason and what about repositories and other gateways for example to external Services aren't entity-centric repositories finally causing unwanted coupling between features I have to admit that most descriptions and images in the book clean architecture in fact indicate towards entity Centric repositories but in the chapter about database gateways we can also read between the use case interactives and the database are the database gateways these gateways are polymorphic interfaces that contain methods for every create read update or delete operation that can be performed by the application on the database for example if the application needs to know the last names of all the users who logged in yesterday then the user Gateway interface will have a method named get last names of users who logged in after that takes a date as its argument and returns a list of last names in the end the clean architecture is not very clear on the detailed design of repositories or other gateways whether those should be part of the vertical slices as well or whether those should be shared across features but considering this text and also the interface segregation Principle as well as the single responsibility principle my conclusion is that in the clean architecture the design of repositories should primarily be driven by the needs of the use case in the actors so in summary in the clean architecture the use case in the actors and the basic control flow in fact do focus on a particular feature and even on a particular request so in this regard the conceptual differences between the clean architecture and the vertical slice architecture are actually much less than initially assumed on the other hand conscious reuse of code that changes at the same time for the same reason is indeed promoted by both architectures finally let's have a closer look at the last concern which is that layers in the clean architecture cause unnecessary abstractions which result in unnecessary complexity I agree the clean architecture has a stronger focus on separation of concerns than the vertical slice architecture has but actually the focus is not so much on strict layers but rather on keeping the domain model and the application logic free from technical details so that these details have ideally no impact on our logic when these change for a lot of different reasons keeping specific Technologies and external Frameworks at arm length might not be that much relevant for a software system of a few thousand lines of code but considering a software system of 100 000 lines of code or even more than one million lines of code not marrying specific Technologies or external Frameworks could even be essential for survival even so in this book clean architecture uncle pop is rather strict on the aspect of separation of concerns I think there are still options to be practical Matic without violating the dependency rule for example if there is actually no application logic required to fulfill a request I usually decide to skip the use case layer altogether and put the code needed right into the controller later on when the code grows an additional logic emerges I apply some refactoring step and extract the logic into some interactor finally the clean architecture is not a silver bullet which fits every single project on Earth if you can get the job done with a few lines of code and the help of some of the uncountable awesome open source libraries then you probably don't need much architecture at all the only remaining challenge for you will be discipline remember especially successful projects tend to remain for longer and tend to accumulate more features over time so don't miss the point where clearer separation of concerns should be in your focus and by that I hope I could demonstrate that the clean architecture is not suggesting to push all your code in four technical layers instead it is actively promoting to organize your code according to features and I hope I could also clearly demonstrate that the clean architecture is not causing tight coupling between features instead it is actively promoting a request oriented control flow which leads to pretty much separated feature-specific code alone the clear focus on keeping the application logic independent from the technical details in fact is resulting in more abstractions but those aren't unnecessary at all from my perspective and if you now think that implementing the clean architecture is more complicated than you thought initially then let me tell you that it actually only takes four simple steps to implement the feature according to the concepts of the clean architecture and these steps you will learn in this video

Channel: About Clean Code

Views: 26,705

Keywords: CleanArchitecture, VerticalSliceArchitecture, SoftwareArchitecture

Id: 7ZXW_oWdTk4

Length: 15min 23sec (923 seconds)

Published: Tue Jul 11 2023