Just my thoughts, as much as I like how clean architecture keeps everything tidy and overall a more flexible way to architect your code, after 14 years of software development in large corporate projects, startups and freelancing consulting... I can count on one hand the times I've seen anyone benefiting from that flexibility. The more we move into smaller microservices, the less value you get out of it. Project changes that require infrastructure changes, often come with other larger changes in the tech stack as well. You often endup needing to rebuild the microservice anyway. I know everyone slags off N-Tier architecture, but for the vast majority of cases it's still the simplest and most efficient way of structuring your code and has a much lower barrier of entry which largely benefits smaller companies. As with any technology always choose what fits better with your team and your business, even if it's not the more "correct" way of doing things.
Clean architecture and microservices aren't mutually exclusive. You can still apply clean architecture principles in microservices. In fact, with each service being scoped and small, it's easier to implement clean architecture and make it, well... cleaner. As to your first point, I think that it's the opposite but it's difficult to prove negative. Once you have clean architecture, it seems like you don't gain much from it. But it's when you don't have you realise how much you could benefit from it. I have a live example of it in my current work, where we have two systems developed in parallel, with only one conforming fully to the clean architecture principles. The one where we don't use it is a perfect example of the broken window theory.
@@ernest1520 I think his point was that there's no benefit of using clean architecture over N-Tier because the scope is small with a microservice and will probably stay that way until EOL.
Yeah, It’s wrong to blindly apply clean architecture to any project. But there are many projects that are a mess since they don’t have a clear boundary between data access logic and business logic. This is especially painful during migration from a monolith to microservices, refactoring, adding features or updating business logic
@@amantinband I get what you saying, but that's not necessarily down to N-Tier architecture for example. You can still apply SOLID principles in N-Tier... legacy projects typically had 3 tiers, where your domain talked directly to the database (infrastructure)... for example you can add a repositories layer in between with interfaces abstraction and you can still replace your infrastructure layers without impacting domain. But my point here was mainly about the fact that the whole concept of microservices is that they are smaller chunks of code with very clear domain boundaries and scopes, and when you have to either change those boundaries and scopes or the underlying infrastructure what you most often see is that teams build an entire new microservice and slowly deprecate the old one. Therefore I'm of the opinion that for the vast majority of businesses that do not have the resources to deal with the overhead of a more complex code architecture, N-Tier is perfectly fine as long as you do it right 😊
@@kewqie Yes, I got his point. However, my point was that clean architecture is in many cases applicable to microservices just like it is to other types of architecture. Do note that I said "in many cases", so of course there will be cases where the microservices are truly so "micro" that introducing clean architecture would be an overkill. Nevertheless, some core principles of clean architecture apply uniformly regardless the size, just like- for example- some principles of DDD can be used in various system, not necessarily conforming to the "full DDD".
I’m really struggling to see how clean architecture is really that different from a layered approach. Maybe there’s an additional layer for domain/entities and another level of indirection. Honestly, drawing architecture using concentric circles and with dependencies upside down just makes the architecture look really different when it’s not that different to layered architecture. The idea that infrastructure is dependent on application logic makes no sense. It’s clearly application logic depends on infrastructure. Just because the arrow is in the wrong direction and there is some intermediate project doesn’t change that. Even if there’s an interface layer that mediates between the application logic and the infrastructure doesn’t change the fact that the application logic layer depends on the infrastructure. Don’t get me wrong I like Uncle bob, but this is just really unclear and confusing. It’s a solution looking for a problem.
Absolutely true. However dependency it is about types and not real world functionality. So when you have type(interface) in app layer and dependent type(implementation of interface) at infrastructure layer that means that infrastructure dependent from app even if real world fact that app layer calls infrastructure layer. Intermediate project here is really about a way of abstracting types away from each other. So they may just sit on different namespaces to get there but more often they separated with projects. All of this can be implemented with 3tier layer architecture with proper IoC and have same good abstraction level. The thing here that ages ago when 3tier was popular DI technique wasn't so popular and references between layers were more strict so 3tier become a synonym of hard coupled architecture.
Not that complicated, you're just confusing term "depends" a bit. There is a source code dependency (having "using" of some class in other class) and flow of control dependency (calling stuff from one assembly in other). And while domain clearly depends on infrastructure on flow of control level, but you can avoid source code dependency by using interfaces and inversion of control. And that will make your app more mantanable, because changes in infrastructure would not affect your domain assemblies.
I'm also having a really hard time understand these concepts. I dont know whats different from calling the database directly from the controller. This has been done through all my university courses and every single youtube tutorial out there and even the laravel documentation. And now WHAT!? Its wrong to write logic in the controllers!?? I really have no idea how everything flipped like that it's either the world is trolling me or i really have no idea about software engineering (im a final year student)
@@charss5416 Basically we can access classes from different namespaces, in another folder, solution, or project. You can organize it any way you want. Tutorials and university courses as well as the official documentation usually use simple examples, the most straightforward way. In the real world they get really large projects. One of the reasons clean architecture is used, is so that it's easier to maintain large projects, So if for example you have to migrate from using SQL Server to another database like PostgreSQL, all you have to change is the infrastructure layer.
The way I look at it, it’s just layered architecture + dependency injection, so nothing new. I’m not sure if they’re just using that confusing diagram and the term “clean architecture” as gimmick to sell their course
@amantinband why do you not use and demo TDD in your course? For me the main reason for using a 'clean' architecture is because you actually get to have fully testable domain and application logic layers. The main guardrail that will keep your product agile and alive. At a minimum it should be mentioned.
Been following your older clean architecture videos before i start my new role and theyve been an amazing help. Architectures can sometimes feel a bit convoluted but you make it easy to follow. Will defo check out your new course in future
Thanks a lot. You described it so well that I could understand it in first try. One request, Please make a long video where you will cover Breakdown the problem description, identify domains, repositories, Entities, settingup a clean architecture project. Thank you.
@@amantinband Yes, I tried in your youtube channel but it was confusing and I lost the sequence of video at some point. So I just hope that If I could get the whole journey in a single session than I would be able to understand all. Clean Architecture, DDD everything sounds so confusing to me.
Hi! Thank you so much! Junior dev and I had learned about Service/Controller/Repository(DAO)/Models, but wasn't sure where all the nuanced extra classes would go. Like those Request & Response objects (Glad to see they go in Controller/Presentation layer!) Where would you put mappers for the domain objects? Would that be in the Repository layer? What about objects for request bodies that aren't domains? Like if I was going to fetch from the DB the settings of a user who belonged to a group. I might have to span multiple tables & it wouldn't fit into just a clean "users" or "settings" object. Where should I put that object?
Just group Application layer and Domain layer into one and call it "Business Logic" layer, then add an abstraction like a repository pattern between Business Logic and Data Access Layer and you will have the same "architecture"
I've always though that architectures are made by people who don't use them. Adding architecture's rule often limit your freedom (and speed) I've just bought your course and it's funny how you break the first rule of clean architecture by referring Infrastructure layer from Presentation layer.
The ONLY difference between N-Tier architecture and Clean architecture is that your interfaces for repository are placed in Application or Business layer instead of data layer (if n-tier application well implemented).
That’s incorrect. It’s actually quite common to place repository interfaces on the domain layer. There are similarities between layered and clean architecture but there are also many differences and nuances
The problem with that is, is it okay for the infrastructure layer to point towards the domain layer? How can the DbContext from infrastructure layer travel to Domain layer?
Hi, I watched a number of videos on the topic and I had questions after each. This video was fantastic and clarified all the questions I had in the previous videos. Thank you!!
Can you please teach us how you use your vscode for dotnet i watched your videos you are so fast at navigating anding breakpoint s and how you use vim in vscode I want to learn to use vscode like you please make a video 🥺🥺🥺🥺🥺🥺🥺🥺 And I am sorry i can't purchase your course because I am from India and I am student but you RUclips videos are also so more useful to thank you and i love your content ❤ please keep uploading
If the Infra layer is referencing the domain layer and not vice versa, how are the Infra implementations being called? Is it through dependency injection in the domain layer? If so, wouldn't that mean the domain layer is referencing the Infra layer after all?
They wont reference themselves. Since the infra layer reference to application layer it implements the abstractions of ifra layer methods in the applicstion layer (or the domain layer) and the application layer does the database interaction by using that ifra layer abstractions. The approach is every layer has its own abstractions that implemented in the infra layer about the database interactions, and when something needed from the database, these infra interfaces will be used. By that way, you try to achieve separation of concerns
Isn't it correct for the domain layer to have repository interfaces instead of the application layer? The domain services could have behavirous that interact with database by repository interface?
I have a question, when applying EF Core or other ORM in our .NET Clean Architecture project then the classes that we perform the mapping on is the entities in the Domain layer or what?
How does this work when using DI in c#, where the service has to be registered in the presentation layer by referencing both the interface AND the implementation? I still have to reference both the infra layer and the application layer from my presentation layer. service.AddScoped();
The 2 clean architecture courses cover everything from the basics to microservices, error handling, testing, authorization etc' on a different app all together
I still dont understand one thing. Application layer doesnt depend on presentation layer, cuz if I change presentation layer it wont affect on application. But if i change an implementation in infrastructure it will affect on application. So how does it work? Sorry for bad eng if it is
Would it be feasible to make http calls to an existing external API? What if ur API contains your domain, can the domain layer be substituted for the API domain? Can the API be a substitute for the presentation layer as well? Thanks for all your hard work and the dedication for disseminating your knowledge to us all. Yourself, Tim Corey, Les Jackson, Chapas and Codewrinkles are a god send for those that love C#.
Hey Adrian. The implementation of web clients sit in the infrastructure layer. Your domain, by definition, cannot sit in an external API. I would recommend taking a look at some open source projects that are structured following clean architecture, I think it will give you some clarity around this 🙂
Just getting started with this and what I can’t find a clear answer on is where database reliant logic lives. If you need to validate that something exists before creating it, is that a domain responsibility or should that kind of logic live in the application layer? I’ve seen examples of injecting services or repositories into the domain layer but that doesn’t feel “clean” at all to me. I’d be interesting know your thoughts?
That’s a great topic that I really like discussing and I cover thoroughly in my DDD course. If the logic is simply orchestrating domain objects then it belongs in the application layer. If the logic is business logic/decision then the short answer is: Passing a repository to a domain object and having it fetch another domain object is called a “disconnected domain model”. This is a form of lazy loading and is usually a sign that the domain isn’t modeled correctly. The alternatives are: 1. Introducing a domain object or updating the current design so that all data needed to make the business decision are part of the domain object. 2. Encapsulating the logic in a domain service. The domain service will fetch data from dependencies and orchestrate the domain objects.
I have a question how do you create a repository implementation in infrastructure without referencing the domain project? 6:41 wouldn’t that mean the infrastructure project would reference the domain?
Hi :) Inside the "Result Pattern" section, should "What is the Result Pattern?" be after "Implementing the Result Pattern"? I think you got the order wrong.
Assuming that the reminderId is unique through the whole system, is there any reason for the api endpoint to be: GET users/{userId}/reminders/{reminderId} Instead of: GET users/reminders/{reminderId} We already have the UserId on the Reminder model (am I right?). Can someone clarify this?
There are various approaches for designing a RESTful API. I like looking at it like folders where the route is the path to a file. Does that make sense?
I've noticed the more devs are into this kind of architecture astronauting the LESS the competent they are at actual dev work. I worked on a complicated networking project that required deep knowledge of the TCP/IP stack, TLS, encryption, routing policies, split tunneling and so on - and the "architecture"-oriented devs were beyond useless. All they had to say was "move this object here, invert that dependency", "this is a use case, this is a domain" - but the actual hard problem of solving the particular issue they were useless at. There's only so much a human brain can hold, and if you fill it up with this "architecture" nonsense, you're generally much less competent in grokking the complicated domain knowledge, the details of how computers or networking actually works! I'm sure it's not true for everyone, but it's absolutely what i've found in my time as a dev.
I think if one were to transition their mindset to "value first" or "responsibility first", you apply some of the principles to the problem space - but you're focused on solving the actual problem them making sure it "fits the mold"
I dont understand it. So we created the services folder to decouple the controller from the database. Then we create a repository to decouple the services from the database. What's the point really? We can keep adding layers of abstraction even between the repository and the data access we can add like 100 more abstraction layers. I don't understand the point.
Point of either 3lauer or clean architecture is to separate concerns, so you can grow and e.g. switch to different persistent layer that can handle scaling better or just switch to ddifferent technology without un tingling thousands of rows of code. But i agree, circular diagram is pure confusion .
I'm still in the beginning of understanding software architecture, but none of this made any sense. I will go and study more, and in the future will return and review to this comment.
100% agree. But I like to have a data interface in application layer and then implement it in a separate project. This is how I can control and nobody will use some framework everywhere in application.
"The application will define some interface for acting with the database" 5:25 "and the outer layers will contain the actual implementation" 5:55 So like... every system ever? Any ORM library which concerns itself with implementation, and the Application is agnostic to how the data is stored or retreived? any "Services file" like Angular has which may use the HTTP library to query the endpoints and not put that logic in the controller? and the controller is agnostic to what the Service is doing to return it data (maybe just mocks, for example)? They all fit that definition. Also, it sounds like your definition of Domain matches the definition of Models or Types
Only those people who don't understand OOPS, Solid principles and design pattern( creational , behavioural and structural type) complaints about these things These three things have literally the solution for everything. And there is a thing called what your software demands. If your software is basic you don't need too much separation of concerns and modulations and all. It depends on your project size and team and hiw much flexibility you want to give...
Unfortunately, IT has a long history of people trying to solve a non-existent problem with a new approach, just for the sake of it. Quotes from the video: “The problem with this is, with time, the business logic often become convoluted with the Data Access Layer logic” & “Business Logic will also end up in the presentation layer” Neither of those are problems with the N Tier layer design, but people putting the logic in the wrong place, which will be a problem in any design and won’t be solved by a new design. When talking about the Clean architecture: “You can switch the presentation layer from a Rest API to a GUI” This can also be done with the N Tier approach, the BL is not dependent on the UI. Maybe there are merits to this approach, but the reasoning mentioned here, is not a valid justification for using a new design approach.
sorry but I just don't see a good justification for having the database layer above the application layer. You can define an interface for / abstract the database wherever it sits.
![[#2024MAMA] BIGBANG (빅뱅) - 뱅뱅뱅 (BANG BANG BANG) + FANTASTIC BABY | Mnet 241123 방송](http://i.ytimg.com/vi/EQsYfiPR9uM/mqdefault.jpg)
Just my thoughts, as much as I like how clean architecture keeps everything tidy and overall a more flexible way to architect your code, after 14 years of software development in large corporate projects, startups and freelancing consulting... I can count on one hand the times I've seen anyone benefiting from that flexibility.
The more we move into smaller microservices, the less value you get out of it. Project changes that require infrastructure changes, often come with other larger changes in the tech stack as well. You often endup needing to rebuild the microservice anyway.
I know everyone slags off N-Tier architecture, but for the vast majority of cases it's still the simplest and most efficient way of structuring your code and has a much lower barrier of entry which largely benefits smaller companies.
As with any technology always choose what fits better with your team and your business, even if it's not the more "correct" way of doing things.
Clean architecture and microservices aren't mutually exclusive. You can still apply clean architecture principles in microservices. In fact, with each service being scoped and small, it's easier to implement clean architecture and make it, well... cleaner.
As to your first point, I think that it's the opposite but it's difficult to prove negative. Once you have clean architecture, it seems like you don't gain much from it. But it's when you don't have you realise how much you could benefit from it. I have a live example of it in my current work, where we have two systems developed in parallel, with only one conforming fully to the clean architecture principles. The one where we don't use it is a perfect example of the broken window theory.
@@ernest1520 I think his point was that there's no benefit of using clean architecture over N-Tier because the scope is small with a microservice and will probably stay that way until EOL.
Yeah, It’s wrong to blindly apply clean architecture to any project. But there are many projects that are a mess since they don’t have a clear boundary between data access logic and business logic. This is especially painful during migration from a monolith to microservices, refactoring, adding features or updating business logic
@@amantinband I get what you saying, but that's not necessarily down to N-Tier architecture for example. You can still apply SOLID principles in N-Tier... legacy projects typically had 3 tiers, where your domain talked directly to the database (infrastructure)... for example you can add a repositories layer in between with interfaces abstraction and you can still replace your infrastructure layers without impacting domain. But my point here was mainly about the fact that the whole concept of microservices is that they are smaller chunks of code with very clear domain boundaries and scopes, and when you have to either change those boundaries and scopes or the underlying infrastructure what you most often see is that teams build an entire new microservice and slowly deprecate the old one. Therefore I'm of the opinion that for the vast majority of businesses that do not have the resources to deal with the overhead of a more complex code architecture, N-Tier is perfectly fine as long as you do it right 😊
@@kewqie Yes, I got his point. However, my point was that clean architecture is in many cases applicable to microservices just like it is to other types of architecture. Do note that I said "in many cases", so of course there will be cases where the microservices are truly so "micro" that introducing clean architecture would be an overkill. Nevertheless, some core principles of clean architecture apply uniformly regardless the size, just like- for example- some principles of DDD can be used in various system, not necessarily conforming to the "full DDD".
I’m really struggling to see how clean architecture is really that different from a layered approach. Maybe there’s an additional layer for domain/entities and another level of indirection. Honestly, drawing architecture using concentric circles and with dependencies upside down just makes the architecture look really different when it’s not that different to layered architecture. The idea that infrastructure is dependent on application logic makes no sense. It’s clearly application logic depends on infrastructure. Just because the arrow is in the wrong direction and there is some intermediate project doesn’t change that. Even if there’s an interface layer that mediates between the application logic and the infrastructure doesn’t change the fact that the application logic layer depends on the infrastructure. Don’t get me wrong I like Uncle bob, but this is just really unclear and confusing. It’s a solution looking for a problem.
Absolutely true.
However dependency it is about types and not real world functionality. So when you have type(interface) in app layer and dependent type(implementation of interface) at infrastructure layer that means that infrastructure dependent from app even if real world fact that app layer calls infrastructure layer. Intermediate project here is really about a way of abstracting types away from each other. So they may just sit on different namespaces to get there but more often they separated with projects.
All of this can be implemented with 3tier layer architecture with proper IoC and have same good abstraction level. The thing here that ages ago when 3tier was popular DI technique wasn't so popular and references between layers were more strict so 3tier become a synonym of hard coupled architecture.
Not that complicated, you're just confusing term "depends" a bit. There is a source code dependency (having "using" of some class in other class) and flow of control dependency (calling stuff from one assembly in other). And while domain clearly depends on infrastructure on flow of control level, but you can avoid source code dependency by using interfaces and inversion of control. And that will make your app more mantanable, because changes in infrastructure would not affect your domain assemblies.
I'm also having a really hard time understand these concepts. I dont know whats different from calling the database directly from the controller. This has been done through all my university courses and every single youtube tutorial out there and even the laravel documentation. And now WHAT!? Its wrong to write logic in the controllers!?? I really have no idea how everything flipped like that it's either the world is trolling me or i really have no idea about software engineering (im a final year student)
@@charss5416 Basically we can access classes from different namespaces, in another folder, solution, or project. You can organize it any way you want. Tutorials and university courses as well as the official documentation usually use simple examples, the most straightforward way. In the real world they get really large projects. One of the reasons clean architecture is used, is so that it's easier to maintain large projects, So if for example you have to migrate from using SQL Server to another database like PostgreSQL, all you have to change is the infrastructure layer.
The way I look at it, it’s just layered architecture + dependency injection, so nothing new. I’m not sure if they’re just using that confusing diagram and the term “clean architecture” as gimmick to sell their course
Already took your 3 courses. Waiting for DDD deep dive. Congratulations on your excellent work!
congrats on course #2 on dometrain! I really enjoy the way you approach your educational content!
Thanks, Kyle! 🙏🏼
@amantinband why do you not use and demo TDD in your course? For me the main reason for using a 'clean' architecture is because you actually get to have fully testable domain and application logic layers. The main guardrail that will keep your product agile and alive.
At a minimum it should be mentioned.
Been following your older clean architecture videos before i start my new role and theyve been an amazing help. Architectures can sometimes feel a bit convoluted but you make it easy to follow. Will defo check out your new course in future
Thanks a lot. You described it so well that I could understand it in first try. One request, Please make a long video where you will cover Breakdown the problem description, identify domains, repositories, Entities, settingup a clean architecture project. Thank you.
I actually do exactly that in detail in my DDD course on dometrain. Did you check it out?
@@amantinband Yes, I tried in your youtube channel but it was confusing and I lost the sequence of video at some point. So I just hope that If I could get the whole journey in a single session than I would be able to understand all. Clean Architecture, DDD everything sounds so confusing to me.
Hi! Thank you so much! Junior dev and I had learned about Service/Controller/Repository(DAO)/Models, but wasn't sure where all the nuanced extra classes would go. Like those Request & Response objects (Glad to see they go in Controller/Presentation layer!)
Where would you put mappers for the domain objects? Would that be in the Repository layer?
What about objects for request bodies that aren't domains? Like if I was going to fetch from the DB the settings of a user who belonged to a group. I might have to span multiple tables & it wouldn't fit into just a clean "users" or "settings" object. Where should I put that object?
Just group Application layer and Domain layer into one and call it "Business Logic" layer, then add an abstraction like a repository pattern between Business Logic and Data Access Layer and you will have the same "architecture"
This is valuable content, sir! Thank you for sharing!
I've always though that architectures are made by people who don't use them. Adding architecture's rule often limit your freedom (and speed)
I've just bought your course and it's funny how you break the first rule of clean architecture by referring Infrastructure layer from Presentation layer.
Thank you. It was explained in the easiest way
The ONLY difference between N-Tier architecture and Clean architecture is that your interfaces for repository are placed in Application or Business layer instead of data layer (if n-tier application well implemented).
That’s incorrect. It’s actually quite common to place repository interfaces on the domain layer. There are similarities between layered and clean architecture but there are also many differences and nuances
@@amantinband How would it sound correct (in case of repository)?
Impressive !!! short and to the point.
You should show the code with practical examples in VS
The problem with that is, is it okay for the infrastructure layer to point towards the domain layer? How can the DbContext from infrastructure layer travel to Domain layer?
when you pointing something in the presentation, which tool you are using?
I noticed that some are putting the interfaces for the repository in the domain layer and others in the application layer. What is the correct way?
4:25 the answer is the I in S.O.L.I.D: dependency Inversion principle
exactly! this is all that's needed. Good old SOLID is enough without this architecture astronauting.
Hi,
I watched a number of videos on the topic and I had questions after each. This video was fantastic and clarified all the questions I had in the previous videos.
Thank you!!
Will you record a video about migration to minimal api from controllers?
Can you please teach us how you use your vscode for dotnet i watched your videos you are so fast at navigating anding breakpoint s and how you use vim in vscode I want to learn to use vscode like you please make a video 🥺🥺🥺🥺🥺🥺🥺🥺
And I am sorry i can't purchase your course because I am from India and I am student but you RUclips videos are also so more useful to thank you and i love your content ❤ please keep uploading
Thank you very much. Excellent explanation.
If the Infra layer is referencing the domain layer and not vice versa, how are the Infra implementations being called? Is it through dependency injection in the domain layer? If so, wouldn't that mean the domain layer is referencing the Infra layer after all?
They wont reference themselves. Since the infra layer reference to application layer it implements the abstractions of ifra layer methods in the applicstion layer (or the domain layer) and the application layer does the database interaction by using that ifra layer abstractions. The approach is every layer has its own abstractions that implemented in the infra layer about the database interactions, and when something needed from the database, these infra interfaces will be used. By that way, you try to achieve separation of concerns
Thank you very much, for your teaching.
Isn't it correct for the domain layer to have repository interfaces instead of the application layer? The domain services could have behavirous that interact with database by repository interface?
Very well explained with visual slides!
I have a question, when applying EF Core or other ORM in our .NET Clean Architecture project then the classes that we perform the mapping on is the entities in the Domain layer or what?
Literally learning clean architecture right now, this’ll be helpful xD
Short nice and clean, thanks a lot!
Great video, very good explanation.
How does this work when using DI in c#, where the service has to be registered in the presentation layer by referencing both the interface AND the implementation? I still have to reference both the infra layer and the application layer from my presentation layer.
service.AddScoped();
How is this new course different from your own great BuberDinner clean architecture series?
The 2 clean architecture courses cover everything from the basics to microservices, error handling, testing, authorization etc' on a different app all together
So, to sum up, the one actual difference between clean architecture and 3-tier is that we use an interface of repo instead of the implementation??))))
Might seem like that but having a separate domain layer is a world of difference, see 3:01
seems like it lol I mean that just a basic solid principle right? depend on interface not implementations
I still dont understand one thing. Application layer doesnt depend on presentation layer, cuz if I change presentation layer it wont affect on application. But if i change an implementation in infrastructure it will affect on application. So how does it work?
Sorry for bad eng if it is
Would it be feasible to make http calls to an existing external API?
What if ur API contains your domain, can the domain layer be substituted for the API domain?
Can the API be a substitute for the presentation layer as well?
Thanks for all your hard work and the dedication for disseminating your knowledge to us all. Yourself, Tim Corey, Les Jackson, Chapas and Codewrinkles are a god send for those that love C#.
Hey Adrian. The implementation of web clients sit in the infrastructure layer. Your domain, by definition, cannot sit in an external API. I would recommend taking a look at some open source projects that are structured following clean architecture, I think it will give you some clarity around this 🙂
which tool do you use for presenting these videos?
Just getting started with this and what I can’t find a clear answer on is where database reliant logic lives. If you need to validate that something exists before creating it, is that a domain responsibility or should that kind of logic live in the application layer? I’ve seen examples of injecting services or repositories into the domain layer but that doesn’t feel “clean” at all to me. I’d be interesting know your thoughts?
That’s a great topic that I really like discussing and I cover thoroughly in my DDD course.
If the logic is simply orchestrating domain objects then it belongs in the application layer.
If the logic is business logic/decision then the short answer is:
Passing a repository to a domain object and having it fetch another domain object is called a “disconnected domain model”. This is a form of lazy loading and is usually a sign that the domain isn’t modeled correctly.
The alternatives are:
1. Introducing a domain object or updating the current design so that all data needed to make the business decision are part of the domain object.
2. Encapsulating the logic in a domain service. The domain service will fetch data from dependencies and orchestrate the domain objects.
Never seen so many boxes and arrows before. To me it's actually a huge distraction. Besides that the video looks nice.
Thanks for the feedback. Never occurred to me it may be distracting
Does anyone know what tool he uses for the graphs/diagrams/slides? 😊
Diagrams - figma. Slides - obsidian
You are the greatest for replying! ❤️
I have a question how do you create a repository implementation in infrastructure without referencing the domain project? 6:41 wouldn’t that mean the infrastructure project would reference the domain?
Hi :) Inside the "Result Pattern" section, should "What is the Result Pattern?" be after "Implementing the Result Pattern"? I think you got the order wrong.
Yeah not sure how that happened! Should be fixed now 🙂
Great explanation!
why not have domain object directly in application layer?
Separation of concerns, and business cases (Application) tend change more frequently than the underlying concept/model (Domain).
is there a way to deploy a web api that is built with clean architecture to azure?
You drew a lot of upwards pointing arrows while explaing this my dude, seems like reinventing the wheel to me.
Great video, i'm wondering what software do you use to draw arrows on the screen?
Presentify. Notice it’s only available for MacOS though
Very informative 👍
Hey Amichai, what tool are you using to draw arrows and boxes?
Presentify but notice that it's available only on MacOS
Please add purchase power parity to the courses if possible.
My course is part of the dometrain platform so I don't control prices/discounts etc'
Assuming that the reminderId is unique through the whole system, is there any reason for the api endpoint to be:
GET users/{userId}/reminders/{reminderId}
Instead of:
GET users/reminders/{reminderId}
We already have the UserId on the Reminder model (am I right?).
Can someone clarify this?
There are various approaches for designing a RESTful API. I like looking at it like folders where the route is the path to a file. Does that make sense?
Thanks for the video, I would like to buy your course but 90 bucks, is too much bro, Anyway, good luck!
Perfect video! Very clear and robust!
I've noticed the more devs are into this kind of architecture astronauting the LESS the competent they are at actual dev work. I worked on a complicated networking project that required deep knowledge of the TCP/IP stack, TLS, encryption, routing policies, split tunneling and so on - and the "architecture"-oriented devs were beyond useless. All they had to say was "move this object here, invert that dependency", "this is a use case, this is a domain" - but the actual hard problem of solving the particular issue they were useless at. There's only so much a human brain can hold, and if you fill it up with this "architecture" nonsense, you're generally much less competent in grokking the complicated domain knowledge, the details of how computers or networking actually works! I'm sure it's not true for everyone, but it's absolutely what i've found in my time as a dev.
I think if one were to transition their mindset to "value first" or "responsibility first", you apply some of the principles to the problem space - but you're focused on solving the actual problem them making sure it "fits the mold"
I dont understand it. So we created the services folder to decouple the controller from the database. Then we create a repository to decouple the services from the database. What's the point really? We can keep adding layers of abstraction even between the repository and the data access we can add like 100 more abstraction layers. I don't understand the point.
Point of either 3lauer or clean architecture is to separate concerns, so you can grow and e.g. switch to different persistent layer that can handle scaling better or just switch to ddifferent technology without un tingling thousands of rows of code. But i agree, circular diagram is pure confusion .
@@Greenmarty Ok I see man thanks! What languages do you work with?
I'm still in the beginning of understanding software architecture, but none of this made any sense. I will go and study more, and in the future will return and review to this comment.
Thanks!
Solution looking for a problem :( Poorly designed/implemented n-tier, is not a problem with n-tier.
100% agree. But I like to have a data interface in application layer and then implement it in a separate project. This is how I can control and nobody will use some framework everywhere in application.
Exactly people don't understand SOLID principles and design patterns and then complain about OOPs....
"The application will define some interface for acting with the database" 5:25 "and the outer layers will contain the actual implementation" 5:55 So like... every system ever? Any ORM library which concerns itself with implementation, and the Application is agnostic to how the data is stored or retreived? any "Services file" like Angular has which may use the HTTP library to query the endpoints and not put that logic in the controller? and the controller is agnostic to what the Service is doing to return it data (maybe just mocks, for example)? They all fit that definition. Also, it sounds like your definition of Domain matches the definition of Models or Types
Only those people who don't understand OOPS, Solid principles and design pattern( creational , behavioural and structural type) complaints about these things
These three things have literally the solution for everything.
And there is a thing called what your software demands. If your software is basic you don't need too much separation of concerns and modulations and all.
It depends on your project size and team and hiw much flexibility you want to give...
Great.!
Unfortunately, IT has a long history of people trying to solve a non-existent problem with a new approach, just for the sake of it.
Quotes from the video:
“The problem with this is, with time, the business logic often become convoluted with the Data Access Layer logic” & “Business Logic will also end up in the presentation layer”
Neither of those are problems with the N Tier layer design, but people putting the logic in the wrong place, which will be a problem in any design and won’t be solved by a new design.
When talking about the Clean architecture:
“You can switch the presentation layer from a Rest API to a GUI”
This can also be done with the N Tier approach, the BL is not dependent on the UI.
Maybe there are merits to this approach, but the reasoning mentioned here, is not a valid justification for using a new design approach.
very useful, thanks
Interesting.
But how and where you will call Infrastructure layer's DependecyInjection ?
You Said very cheap? ohh ok.
Good explanation but damn you pause a lot while speaking, it makes it super hard to actually listen to you my guy
Between sentences? Or as part of the sentence? Would you have preferred a cut there or for me to pause for less time? Lmk so I can improve 🫶🏼
3:12 how can data access layer ends up in presentation layers if follow the principals?
sorry but I just don't see a good justification for having the database layer above the application layer. You can define an interface for / abstract the database wherever it sits.
When not above the database can know about the application...