Understand Clean Architecture in 7 Minutes

clean architecture is an architectural pattern that puts the focus on the domain that's why it's a domain-centric architectural pattern and as you can see we have various logical components that have well-defined interactions with one another now before we jump into an example and we take a look at what the system can actually look like I want to announce my brand new course that just came out yesterday getting started with clean architecture this is the most comprehensive course that you'll find out there for getting started with clean architecture I've also made sure to cover all the various patterns that you'll likely see in clean architecture structured Solutions in production like the repository pattern sticker RS unit of work mediator result everything that you need to look at any clean architecture structure solution and understand what's going on and to have a holistic understanding of clean architecture don't train gave me 200 promo codes to give out that will give you a 20 discount so make sure to check out the curriculum and then check out use the promo code that you see on the screen so back to the video Let's imagine that we have an application for setting reminders so we can go ahead and imagine an API similar to this where we have options to create reminders delete reminders and fetch reminders and just to make it a bit more interesting let's imagine that in the basic plan you can set up to three daily reminders and if you want more than that then you can go ahead and purchase this very cheap subscription that will give you unlimited daily reminders now to understand what I mean by a domain Centric architectural pattern I want us to go ahead and compare the 3-tier architecture to clean architecture so let's imagine that over here we have the client or the user and no matter how our project is structured they'll go ahead and interact with the presentation layer so the presentation layer is responsible for interactions with the outside world we're defining a rest API so we'll have the controllers Etc sitting in the presentation layer if we were working with graphql or grpc or some Spa then those would sit in the presentation layer as well now this is where we becomes a bit more interesting so let's imagine that we're trying to set a reminder so we go ahead and we call our API in the presentation layer and now we need to go ahead and actually create the reminder now like we said there are different subscription types so there's some business logic that we need to make a decision whether or not the user can set a reminder or maybe they've reached their maximum limit now in the three tier architecture then everything sits over here in the business layer now as you can see there's a dependency from the business logic to the data access layer meaning that the data access layer which has the data access logic is accessible from the business logic and the way this is usually implemented is that each one of these will be a project and over here we'll have some project reference between them and then the symbols in the code in the business logic can go ahead and interact with the symbols in the code in that data access layer now the problem with this is that with time the business logic often becomes convoluted with the data access layer logic and also because the presentation layer also has a dependency on the business logic then the presentation layer transitively also has a dependency on the data access logic and sometimes data access logic will also end up in the presentation layer now if we go ahead and compare all of this to the clean architecture then we can see that now the business logic isn't just in one layer but it's in two different layers where the application layer contains all the various use cases so set reminder dismiss reminder delete reminder all of these are use cases or features inside our system and they will sit in the application layer the domain layer will have the definition of all the various domain objects so the actual reminder the user the definitions will sit in the domain layer and the application layer will be responsible for orchestrating all the various domain objects and calling all the various methods like adding the actual reminder object to the user object now if you've noticed unlike of the layered architecture the database isn't in the bottom so over here all the dependencies are pointing towards the database if we look at the clean architecture then these concerns are sitting in the infrastructure layer and that's why it's called a domain Centric architecture because the domain is in the center or over here you can see all the dependencies point towards the domain now if you're wondering how can it be that the core logic of the application doesn't have a dependency on the database so at some point we'll want to go ahead and access the database from the use case or from the domain how is this possible if there's no dependency the other way around so the beauty about all these architectures is that when there's this clear dependency between the layers we can go ahead and replace the underlying technology or framework in the outer layers and it doesn't affect the inner layers which means that we can go ahead and switch the presentation layer technology from a rest API to some GUI for example and it won't affect the business logic because it just goes ahead and manipulates the business logic in a different way so if this is the case how can it be that the infrastructure is above and this contains the data access logic if the core logic of the application is over here at some point like we said we'll want to go ahead and interact with the database so the quick answer is that the inner layers Define interfaces and the outer layers Define the implementation to these interfaces so the application layer will go ahead and Define some interface for interacting with the database and the actual implementation will sit in the infrastructure layer so looking at what a solution may look like so like we said the presentation layer is responsible for interaction with the outside world that's why we have over here the controller and the definition of the actual API then we have the application layer the application layer like we said has the various use cases so set reminder dismiss reminder all of these are use cases in our system and also the inner layers like we said it Define the interfaces and the outer layers have the actual implementation so if one of the use cases needs something from the database it goes ahead and it adds the corresponding method to the interface but the actual implementation is abstracted away to the infrastructure layer then in the domain layer so we have the actual objects right so the user the reminder and the business logic and rules so for example when we go ahead and we create a new reminder then we add the reminder object to the user object and over there we might have an if statement that checks the plan type and it sees if the user can create this reminder or not then finally we have the infrastructure layer and the actual implementation of how to access the database or infrastructure concerns in general like interacting with the file system the system clock Etc all of this will sit in the infrastructure layer now of course there are many many other nuances that you need to know when working with clean architecture but that's it for this short video so if this is interesting make sure to check out the course and if you enjoyed this video then make sure to smash the like button smash the Subscribe button and I'll see you in the next one

Channel: Amichai Mantinband

Views: 33,406

Keywords:

Id: 1OLSE6tX71Y

Length: 7min 1sec (421 seconds)

Published: Thu Sep 28 2023