Video TQdLgzVk2T8

[00:00] If you've been following along with my channel, you know I'm a big fan of the clean architecture. So in this video, I wanted to give you a high-level theoretical introduction into the clean architecture. I want to explain what the clean architecture is, which components go where, what are the benefits of using the clean architecture,

[00:17] and when you should be using this architectural approach. This is the visual representation of the clean architecture, and I first want to explain what the clean architecture is. it's an opinionated way to structure your code.

[00:31] What I mean by this is the PIN architecture is prescriptive because it defines how you should structure your applications. You should be placing your business rules at the system's core and the system's core is represented with the domain and the application layers.

[00:46] The other layers in the architecture, which are the presentation and the infrastructure layer, represent external dependencies to your system and they should be treated as details, quote-unquote. I place this in quotes on purpose because I don't completely agree with this idea,

[01:01] and I prefer a more pragmatic approach when it comes to the clean architecture. But first, let's look at the high-level structure of the clean architecture. We have the core business logic sitting inside of the domain layer. The domain layer shouldn't have a reference to the other components or layers in the system,

[01:17] and it should be able to express the business logic on its own. Then we have the application layer, which contains the application's use cases, and it orchestrates the domain. We also have the presentation layer, which basically acts as an

[01:30] entry point into our system, and it contains the public API. This could be a REST API, a Blazor application, a gRPC service, it doesn't really matter. The role of the presentation layer is to

[01:42] take in an incoming request and then delegate it to the appropriate use case. We also have the infrastructure layer, which deals with external services. Now, when it comes to software architecture, we want to talk about the architectural principles that the software architecture that we decided to use in our system will give us.

[02:00] These principles could be maintainability, testability, and loose coupling, and Clean Architecture delivers all three of these qualities when implemented correctly. You also want to follow some high-level design principles that are going to ensure that you build a quality system.

[02:15] These principles are the separation of concerns, encapsulation, dependency inversion, explicit dependencies, single responsibility, and the persistence-ignorance principle. All of these design principles are closely aligned with the concepts and ideas that are promoted by the clean architecture.

[02:32] For example, we have the separation of concerns principle, which states that we should structure our system in such a way that each component has a specific responsibility. When you think about this on the architectural level, clean architecture promotes this by placing the business logic in the domain layer,

[02:47] and then the use cases as another concern in the application layer, and we try to implement the use cases to be independent of external concerns by moving that responsibility to the infrastructure layer.

[02:59] Another very important design principle that clean architecture follows is dependency inversion. What this means when it comes to the clean architecture is that the other layers are allowed to reference the inner layers in the architecture,

[03:12] so the application layer can reference the domain, the infrastructure layer can reference the application and the infrastructure and presentation layers can reference each other because they sit on the same level of abstraction on the outskirts of the architecture

[03:25] So as I said, the dependencies flow inwards, and the inner layers define interfaces or abstractions. What this means in practice is, let's take an example that you want to talk to a notification service, such as AWS SNS.

[03:38] you will create an abstraction or interface in the application layer, and then use that interface in your use cases to talk with the SMS service. The implementation of this interface is going to live in the outer layer,

[03:51] in this case the infrastructure layer, and we're going to provide the implementation at runtime using dependency injection. Another way to think about the clean architecture is that it's a domain-centric approach to organizing your dependencies.

[04:03] The practical benefits of the dependency inversion principle is that it allows your application core to be free of external concerns, although to which degree you will be able to implement this depends on how good your abstractions are

[04:16] and how much of the external concerns you want to abstract in the first place. This should allow you to be able to easily, again, quote-unquote, replace external dependencies, and why easily is inside of quotes

[04:28] is because it's not that simple to replace all external dependencies. For example, going from one database system to another is a very big undertaking, but replacing an email notification service, for example, switching from MailChance to something else,

[04:42] is not nearly as difficult as changing the database system. So, not all abstractions are created equal, and not all external dependencies are so easily replaced. So now let's discuss the individual layers of the clean architecture and what we should

[04:56] be placing inside of these layers. And I'm going to begin with the domain layer, which sits at the core of the architecture. Here you will see things like domain entities containing your business rules, value objects, domain events, domain services, interfaces for any abstractions that are required by the domain layer.

[05:14] This could be repository interfaces, and it's something I commonly do, but it could also be an abstraction for some other component in your system. Then you're going to have exceptions. If you need to use exceptions to express some situations in your domain.

[05:26] And last but not least, you can have enums in the domain layer. If we go one level above, we have the application layer, and the purpose of the application layer is to orchestrate the domain. This means that the application layer is responsible for telling the domain entities and the other components in the domain what they should be doing.

[05:45] The application layer also contains business logic, and we can call this the application business logic. and what this will mean in practice is the application layer is responsible for checking any preconditions and then telling the domain layer what they should be doing.

[05:58] The application layer defines the use cases, which represent the individual features in your system, and you can implement these use cases using application services, which is a very common approach, or the approach that I like to use, which is implementing CQRS with the mediator library.

[06:14] Both approaches are correct, and it's up to you to decide what you want to use to implement your application use cases. If we continue with the clean architecture layers, the next one is the infrastructure layer and it's responsible for interacting with the external systems that our application

[06:30] needs to function correctly. These could be databases messaging components like RabbitMQ or AWS Simple Queue service email providers like MailChimp storage services like Azure Blob Storage or S3 identity providers like KeyFloak or Auth0

[06:46] and even something trivial like the system Clock. And then right next to the infrastructure layer, we have the presentation layer, and it defines the entry point into the system. The practical implementation could be a gRPC service that defines the gRPC methods

[07:00] other components can call to interact with our system, or it could be a RESTful API, and this is the most common implementation in .NET. In the presentation layer, you would implement your API endpoints, middleware, and dependency injection setup.

[07:14] Now, I mentioned earlier that I like to use CQRS to implement my application layer use cases. And the question is, do you need to use CQRS? Well, no, you absolutely do not need to use CQRS, even though I often do it.

[07:28] And you can implement your application use cases just fine in simple service classes. but there are some benefits to using CQRS that I enjoy, which is why I like to implement this pattern. And the pros of CQRS are the single responsibility principle,

[07:43] so each command or query handler is responsible for only one thing or one use case. You also get the interface segregation principle, the decorator pattern because you can use mediator's pipeline behavior, and you get loose coupling because you only have to worry about sending the appropriate query or command,

[07:59] and you don't need to know what implementing is. The cons of CQRS, really, there's only one when it comes to the implementation with Mediator, and this is indirections. There is a bit of reflection magic going on to connect your command or query object to

[08:13] the appropriate handler. So, debugging isn't that straightforward, but I don't find this a big enough problem to deter me from using CQRS with Mediator. Here's a high-level view of my system from my API as the entry point.

[08:26] So, this would be my presentation layer, which takes in an incoming API request, and And then it turns it either into a query or a command. Let's first look at the query flow. So we have a query object that's going to be sent from our entry point, which is going

[08:40] to be the endpoint, to the respective query handler. In the implementation, you can decide what you want to use to execute your query. I like to write raw SQL queries with dapper because I get excellent performance, and I

[08:53] can return a specific data model or read model that exactly matches the query that I'm executing. So the query handler would send a SQL query to the database, the database gives me back the result, and I just return this from the handler to the endpoint and back to the user.

[09:08] You can see that the overall flow is very simple because there typically isn't too much going on on the query side, and if you do have some business logic, it's mainly about authorization and determining if the user can access something or not, or you could be

[09:21] running some complex calculation before you can return the result back to the user. On the command side, which is responsible for updating the database, we package up the incoming request into a command object and we delegate this to the respective command

[09:34] handler. I will usually implement the command handlers using EF Core, hidden behind a repository of abstraction and domain-driven design in my domain layer. So the first step will typically be using the repository to talk with the database and

[09:47] get back our domain entities. Then we're going to call our domain entities to execute the business logic. And finally we going to use EF Core with a unit of work subtraction to save the changes to the database So the overall flow is a bit more complex but this is because I want to encapsulate the business logic into my

[10:05] domain layer and I want to make my use cases or command handlers as testable as possible, which is why I will often use repository and unit of work abstractions in my use cases. The next question is

[10:17] where you should be using clean architecture and really it makes sense anywhere. It works inside of a monolith, it works inside of a modular monolith, and it also works inside of microservices. So there's no real limitation where you can use clean architecture, but you should think about

[10:32] where you should be using clean architecture. And I want to give you a few points where clean architecture makes a lot of sense. Clean architecture is a perfect fit if you want to use domain-driven design or you want to solve complex business logic. Because it's a domain-centric architecture,

[10:47] you will be able to structure your business logic into the application core, which consists of the application and the domain layers. Another benefit of clean architecture is that it's highly testable, so if you have a requirement to build a highly testable system,

[11:00] clean architecture could be a good choice. And lastly, if you want your architecture to also enforce your design policies, clean architecture could be a good fit, because it's an opinionated approach to how you should structure your system.

[11:14] Clean architecture already defines the high-level components of your system, and then it's up to you how closely you want to follow these guidelines. Now, what should your next steps be if you want to master the clean architecture?

[11:26] Well, first of all, I have a ton of free videos about clean architecture on this channel, and I'm pretty sure I covered almost any topic that comes to mind. However, if you want a more structured approach to learning clean architecture, like a complete

[11:40] blueprint for building production-ready applications using clean architecture, then you might enjoy pragmatic clean architecture. So what is pragmatic clean architecture? It's a comprehensive course that covers the clean architecture fundamentals.

[11:53] It teaches you how to build a rich domain layer with domain-driven design, how to design a clean application layer, and the infrastructure layer to encapsulate external dependencies. It's also going to show you how to build a presentation layer using controllers and minimal APIs,

[12:08] how to integrate authentication with KeyFloak, and how to extend this to support role-based and permission-based authorization. It's also going to teach you some advanced features for building production-grade systems like structured logging, monitoring, API versioning.

[12:22] And of course, you're going to learn how to build a high-quality test case that contains unit tests, integration tests, functional tests, and architecture tests. The students who completed the course said they got a lot of value from Pragmatic Clean Architecture,

[12:35] and all of these reviews are public on my website. A few months ago, I released Pragmatic Clean Architecture version 2, and it comes with 10 in-depth chapters and more than 90 video lessons. They're also going to build a complex system completely from scratch,

[12:49] and I included the source code with some additional features as a bonus. The course also includes a bonus Clean Architecture template, a code quality shortcut, and the continuous integration and development blueprint. You're also going to get lifetime access and updates,

[13:03] and if you want to go through the course with other engineers, then you can also get the community access version. If this sounds interesting to you, then you can learn more about Pragmatically in Architecture from the pinned comment under this video.

[13:15] Thanks a lot for watching, and until next time, stay awesome.