Video eUW2CYAT1Nk

[00:00] In today's video, we'll talk about the difference between clean architecture and domain-driven design. In the workshops that I teach about clean architecture in DVD, I like asking participants, do they know the difference between the two? Almost everyone gets this wrong or doesn't know,

[00:15] even though they are completely different things. So let's talk about what clean architecture is, what domain-driven design is, and why even though they often come together, they're actually completely different things. Also, if for some reason you're not subscribed yet,

[00:27] then don't even pause the video, smash the subscribe button, and let's get started. So let's start with Korean Architecture. So Korean Architecture is a suggestion for how to take your code and split it up into different components.

[00:41] So let's imagine we have over here two components. Let's say one of them is Component A, and the other one is Component B. Now when I say Component, it can be different code sitting in different folders.

[00:53] It can be code sitting in different projects. you can theoretically be two pieces of code inside the same file with a clear separation between them. Now, the underlying idea in clean architecture is that if you have component A, for example,

[01:06] responsible for interacting with the user or the client, so all the concerns that have to do with what the web page will look like, what the endpoints will look like, etc., depending on the framework or technology that you're using,

[01:20] if you have all these concerns sitting in component A, and everything else in your system sits under component B, and you have a clear relationship where component A uses component B,

[01:33] but not the other way around, then once you have this operation of concern, you can theoretically take component A and replace it completely with a different component, a different technology. For example, you want to switch from using HTTP and JSON

[01:47] to using gRPC or GraphQL, or you want to switch from React to some other front-end framework, you can theoretically do this without affecting Component B at all, because there is no dependency between Component B to Component A.

[02:01] Also, in the example that we gave, now we have Component B that has all the core logic of our application. Component B can now be tested completely and in an isolated way, without taking into account that technology that we're using to interact with the user.

[02:17] So we can go ahead, like we said, and replace component A with something else, and we still have these tests that are validating that component B, the core logic, is working as we expect. Now looking at the diagram of clean architecture, we can see that all we have are components with

[02:32] well-defined interactions with one another. In clean architecture, each one of these components is called Raider, and each one of the Raiders in clean architecture has a specific responsibility.

[02:44] For example what we said about component A where it interacts with the yuga that is the presentation layer responsibility So interacting with the Yuga will be via the presentation layer Component B or the core logic of the application

[02:58] sits inside the application and domain layers, and this is actually often referred to as the core. And the infrastructure layer is the implementation detail of various technologies that we decided to use.

[03:11] So, for example, when we want to interact with some other web API, then the HTTP clients and implementation itself will fit in the infrastructure layer. Another example is the implementation details of how we interact with the database.

[03:24] All these various implementation details that don't have to do with the actual core logic of the application will be abstracted away to the infrastructure layer. Now, this is where it becomes a bit more interesting,

[03:36] specifically when we take the application and domain layers and we look at it and its relationship to domain domain design. Before we continue, I want to remind you that I have three comprehensive courses on DomeCrain. So if you enjoyed this video, then alongside subscribing, make sure to check out these courses.

[03:50] Now, back to the video. So let's imagine that we're working on a system for banking. So let's look at a scenario where a user wants to go ahead and open a bank account. So over here we have some banking system.

[04:04] Now, as we said, the presentation layer is responsible for interacting with the user. So the user will go to the web interface, enter all their various details, and they'll click and get on a button of Open Bank Town. The presentation layer, like we said, doesn't execute anything that has to do with the business.

[04:19] But all it does is it takes the incoming data, let's say make sure that it's valid, it returns an error to the user if not. But what it's responsible to do is to invoke the correct logic in the core of the application.

[04:32] So, as I mentioned, we have some banking service object that has inside a method called create bank account. So, the presentation layer goes ahead and invokes this method in the application layer. The application layer is responsible to orchestrate the use case or the scenario, the feature that we're doing.

[04:50] So, in our case, we want to open a bank account. It makes sense that before we can open a bank account, we first need to check against the government if the user is eligible to open a bank account. Or perhaps in our database,

[05:03] we see that the user owes a lot of money from a previous bank account that they have, and we don't want to allow the user to open a bank account. So let's imagine that over here we have some government service, and also we have the database.

[05:16] Like we said, the implementation details, how to talk to the database or to various other services fits in the infrastructure layer. So over here we have the clients that know how to interact with these various components, but the application layer doesn't care

[05:29] about the actual implementation detail. So the application layer has here some interfaces that it interacts with, where under the head it goes ahead and invokes the corresponding logic in the infrastructure layer So the application layer is responsible like we said to orchestrate the use case In our case we need to go ahead and call the government service and call the database etc

[05:49] The application layer will go ahead and orchestrate, calling all these various components, and finally, let's say, creating the account object, creating maybe the user object or adding the account object to the user object.

[06:02] The orchestration of this entire process is done by the application layer. Now, you may be asking yourself, what the heck is left for the domain layer? So if that's what the application layer does, then what is left?

[06:15] Well, the domain layer is responsible for anything that has to do with business logic, business decisions, business terminology. So for example, the actual decision, the computation, based on the various data that we have,

[06:33] the decision whether or not the user is eligible to open a bank account, this is under the responsibility of the delete so the domain layer will have the actual logic that decides okay if their score from the government is over X then

[06:47] they can open a bank account if their debt is over Y then they can't open a bank account these decisions are in the domain also all these various entities that we have like the account the bank the user all of these will fit in the

[07:02] domain layer and ideally want to encapsulate the logic of the business all these various decisions inside these objects. Okay, now let's talk about domain-driven design. Domain-driven design

[07:14] is an approach for developing systems where the underlying idea is to give you a clear mental map of the domain that you're working within. So going along with a banking example,

[07:28] So before we go ahead and develop such a system, we want to know what we're getting into. We want to explore what's called the problem space. It makes sense that in the banking world, based on the different countries, you'll have different rules, different regulations.

[07:46] Perhaps different age groups have different rules. we want to explore the problem space, understand what we're facing before we start building the system with the goal of creating software that resembles the domain that we're working in.

[08:03] Now you need to ask yourself, how can the code, the system, the implementation, how can it resemble the domain? So the way this looks is we want the terms, the terminology, you, the names of the methods, the names of the objects, to be the same as the ones that

[08:20] the domain experts use. Then, when you talk to the domain expert and they tell you there's a new regulation, blah, blah, blah, to explain to you what's happening, then you know what it means in your application, and you don need to do a mapping between okay when he says A I know what my system is called B Now my explanation up until now sounds a bit abstract for domain design like exploring the problem space

[08:40] But domain-to-read design is actually a set of concepts and tools and practices that you can take to explore the domain. So, the various practices like event-forming, event modeling, things that help you explore the problem space that you're working in.

[08:57] Then you have various phases like strategic design and tactical design, where you take the problem space and you break it up into smaller subdomains, you decide what's more important. You can maybe delegate an entire responsibility subdomain to a third party.

[09:11] Maybe there's an off-the-shelf solution for that concern that you have. Then, once you've decided what systems you want to build, where you want to put your energy, then you have pretty strict rules regarding what type of object you can create.

[09:28] So, you have factors for creating a domain object, where a domain object is either an aggregate, an entity, and a value object, where each one of the entities needs to be contained inside an aggregate.

[09:41] An aggregate can be contained inside other aggregates. So you have all these various guidelines that help you write the underlying code before you write any of the code. So you can decide how you want to model your domain.

[09:53] The architects can sit and decide, this is what I want the domain to look like. And it's a pretty straightforward mapping from there to the code base, where you go from something that was very amorphic in the beginning to the actual code implementation.

[10:08] Now, let's talk about the relationship between clean architecture and domain-driven design. So, like we said, in clean architecture, the application and domain layers are what's referred to as the core of the application. You can go ahead and implement the core of the application in whatever way you want, right?

[10:26] There's no restriction about what you need to use over here and over here. Domain-driven design is often used as the implementation of the core of the application. So for example, in Domain-Greman Design, there is a tactical pattern called Repository.

[10:43] The repository will fit either in the domain layer or the application layer. Then you have other tactical patterns like aggregates, entities, value objects. All these will fit in the domain layer.

[10:55] So as you can see, when you follow Domain-Greman Design, it makes sense to use a domain-centric architectural pattern where you take the ideas and the concepts, the principles from domain-centric design, you apply them and it fits in the core of the application.

[11:11] That's why you will see domain-centric design used in Kuna architecture and various other domain-centric architectural patterns. So that's it for this video. I hope you enjoyed it and you learned something new. Make sure to smash the like button, smash the subscribe button and I'll see you in the next one.