Awesome work and material! I've got some feedback on things that may be misleading in the video: The DDD book (that picture you put in the video) does not speak about event-storming or any tooling to do the domain design itself. The layers shouldn't call outwards (as you showed on application layer), they should only call inwards. So that domain can't call application, application can't call presentation... "Business logic" that you mention speaking about the domain layer is a bit cryptic, as it's not only about logic and "business" word is also not on point since what database you choose, how you call your database etc. at the end is also part of the business. There may be a point in your design (especially at the beginning, but depends on the problem you are trying to solve) that indeed it is a detail, but all of that is part of the business. The more important part is that through design you are able to better decide what can be postponed and what needs to be done right now. So the "domain" layer is more about separating what's the language and concepts that stakeholders use (experts, business people, devs..) and separating it from technical decisions and other parts of the codebase. And here we could say that calling a database is separate from that language, although it's part of that business, but it's a part we don't need to exchange. They won't care if we use postgress or datomic and we do a query with that and that syntax, it's not something worth communicating over. Even though it is part of our business as it can affect performance, security of the data and so on. So in short: Clean/Onion/Ports&Adapters/Hexagonal/Layerd Architecture (so many names...) is just a type of software architecture, structuring of the code and its relations that is advised to use with DDD as it helps separate the domain DDD is about bringing all stakeholders (business people, developers, designers, experts...) to talk together and plan the software that is going to be made, which should result in code reflecting better it's intent, reducing misalignment between "business people" requirements and technical teams and enable better cooperation for future (easier applying changes, easier to exchange on topics, more accurate estimations...)
"Repositories go into either the application or domain layers" I believe their implementation goes into the infrastructure layer, but their definition (if you're working with interfaces/headers/protocols) belongs to the domain layer. This keeps the domain from being dependent on the infra layer, while still making use of it, often through dependency injection
@@amantinband maybe an example project of bank where each module is divided in it's own layer as you explained. where will be the UI, where will go the validations, models, business logic and where will be the db access layer etc..
But how can you have CA without DDD? it means orchestration, business rules, will all reside in application layer and not domain? domain layer will be just classes with getter and setter? no behavior, no domain services (as business rules and domain logic is not part of domain layer responsibility? but shifted to higher level? in that case application layer? ) and if my above statement is correct, then what i will benefit from not using ddd and put all the effort and or (write all code) to application layer? It seems to me that once you separate these layers (CA) (especially for large applications) and you know what ddd is, i can't think myself not doing ddd. My reply is not about judging if using ddd is better than not doing it, but rather to understand better the differences and if any, the benefits of not using ddd. ( if any) i also realize that i use both. My domain layer contains, (IRepositoies, Entities with behavior (AR), some value objects, and domain services (some of them make use of repository interfaces , some other just accepting ARoots) to perform some operations or return back ARoots . the infrastructure layer which is the implementation of my repositories and or any other technical concerns Application layer that as you very well mention is just orchestrating and call out the domain services , or loading some AR , call some methods and persist back, Not too much logic, and if possible nothing at all in application layer.
This was one of the key points in my latest video too. This common misunderstanding is very widespread and one of the major reasons why people tend to struggle with understanding software architecture in general.
I just don't get why Infrastructure arrow is not from application to infrastructure. If Databases are in infrastructure, wouldn't the application be the one who's calling the infrastructure?
Researching more about the matter, the arrows are not calling process, but dependency. For implementation, Application layer could just call interfaces. Infrastructure implements those interfaces and then actually store and read data from DB.
I really like these videos because Amichai talks about the more advanced concepts that are not covered anywhere else on the internet. Because in todays market of developers, you are not getting hired with your typical self-taught You-Tube education. Your projects are going to need some complexity to showcase that you are not just some code-monkey, or react-andy. Before these videos I could not map a domain to schema, or had any idea on to create a domain to begin with. I feel like I had that level of professionalism to my projects needed to get noticed by employers. I think the only thing I have not seen on the internet is how domain events are implemented together with something like Mass Transit or RabbitMQ. Excellent explanation of how separation of concerns synergizes with battle tested patterns and architectural principals to produce quality code.
Agreed what you just said. Also, it's required to understand that DDD != CA. I have seen people claim they have done DDD because they have implemented CA. Which is wrong. DDD can be used to model your problem domain but it should not influence CA. A tactical design decision tree can be used to identify business logic patterns and architecture patterns based on the subdomain identified (supporting, generic, and core)
Really good vid. However, I kinda got confused when you started talking about the Application layer. Why do you have the application layer talking to the Infra layer? I thought the application layer can only communicate with the domain layer.
As far as I know application layer orchestrate the communiticatiin between presentation layer, domain and infrastructure. But however I'm confused why he said repositories are written in application layer. Because I thought infrastructure and repositories where the same
I feel like this is always explained a bit differently, as originally, the domain layer would contain all interfaces and definitions, and the application layer would implement them in the usecases. so strictly speaking the business "code" is in the application, while the domain only describes, but has no logic, however sets the domain language.
From CA i am not sure that domain layer should contain logic, why is it not in application layer? as part of orchestration. In my experience, domain layer mostly contains domain entities, some constants and hmm maybe some exceptions
Thanks for your videos, Amichai. My question will sound very specific but who knows... In my industry, experts are referring to real-world objects as "manufacturable" and "manufactured". But the current codebase refers to the corresponding entities as "manufacturableMachine" and "manufacturedMachine". Is there any recommendation on using either language in the codebase? The actual spoken terms, or more formal terms? Or if there is any kind of standard regarding this question, is it bothersome that the words used to refer to these entities are adjectives or past participles?
DDD is language agnostic, and the course would be very similar. The Clean Architecture part would be implemented differently, using different libraries and tools, but would also look very similar. Maybe in general I do think it is a good idea to port the courses to other languages as well to help viewers understand the content in their preferred language, but don't think I'll have time for it in the foreseeable future
Hey Amichai, would it be possible to share the figma files/link for the diagrams/designs you've used in your CA-template? That way we could make similar diagrams for our projects, or update the ones you've used.
Answered on GitHub, but will drop the link to the figma communite plugin here as well for anyone coming across this comment: www.figma.com/community/file/1334042945934670571/clean-architecture-project-file-system
Hey, I don't have a section that covers specifically the difference between the two (maybe that's a good idea for future courses). I have in depth courses on both CA and DDD so I would like to believe that viewers would know the difference, but maybe a dedicated sub-section is a good idea for the future
Hey Amichai, What do you think about the idea of using Clean Architecture for Modules in a Modular Monolith? On a first glimpse it seems like a good idea, especially since the Data Access can often get messy and Data Access across different Modules is made. With one Infrastructure layer, that wouldn't seem so wrong and confusing.
Using CA with modular monoliths is very common. Regrading infra, most solutions create an infra layer per module. Shared resources would be extracted to a common project if needed, but each of the modules would have it's own ifra layer
@@amantinband thank you! The common project is a good idea. In fhe data access we have a lot of cases where many Databases are joined together in each modules data access. That's why I was thinking of one Infra
![[TH] FS vs BME - VCT Ascension Pacific - Lower Bracket Final](http://i.ytimg.com/vi/wnygqsR2Fig/mqdefault.jpg)
Awesome work and material!
I've got some feedback on things that may be misleading in the video:
The DDD book (that picture you put in the video) does not speak about event-storming or any tooling to do the domain design itself.
The layers shouldn't call outwards (as you showed on application layer), they should only call inwards.
So that domain can't call application, application can't call presentation...
"Business logic" that you mention speaking about the domain layer is a bit cryptic, as it's not only about logic and "business" word is also not on point since what database you choose, how you call your database etc. at the end is also part of the business. There may be a point in your design (especially at the beginning, but depends on the problem you are trying to solve) that indeed it is a detail, but all of that is part of the business. The more important part is that through design you are able to better decide what can be postponed and what needs to be done right now.
So the "domain" layer is more about separating what's the language and concepts that stakeholders use (experts, business people, devs..) and separating it from technical decisions and other parts of the codebase.
And here we could say that calling a database is separate from that language, although it's part of that business, but it's a part we don't need to exchange. They won't care if we use postgress or datomic and we do a query with that and that syntax, it's not something worth communicating over. Even though it is part of our business as it can affect performance, security of the data and so on.
So in short:
Clean/Onion/Ports&Adapters/Hexagonal/Layerd Architecture (so many names...) is just a type of software architecture, structuring of the code and its relations that is advised to use with DDD as it helps separate the domain
DDD is about bringing all stakeholders (business people, developers, designers, experts...) to talk together and plan the software that is going to be made, which should result in code reflecting better it's intent, reducing misalignment between "business people" requirements and technical teams and enable better cooperation for future (easier applying changes, easier to exchange on topics, more accurate estimations...)
You can’t make me understand. I refuse to
😂you just have to
"Repositories go into either the application or domain layers" I believe their implementation goes into the infrastructure layer, but their definition (if you're working with interfaces/headers/protocols) belongs to the domain layer. This keeps the domain from being dependent on the infra layer, while still making use of it, often through dependency injection
Really interesting concepts, sometimes it's good to get away from the code and look at the actual concepts.
it would be really good if you can show an example project.
What specifically would you like to see?
@@amantinband maybe an example project of bank where each module is divided in it's own layer as you explained. where will be the UI, where will go the validations, models, business logic and where will be the db access layer etc..
I did something similar in this video, check it out - th-cam.com/video/1OLSE6tX71Y/w-d-xo.htmlsi=k7Xh-tnPnGHWTJz3
But how can you have CA without DDD? it means orchestration, business rules, will all reside in application layer and not domain? domain layer will be just classes with getter and setter?
no behavior, no domain services (as business rules and domain logic is not part of domain layer responsibility? but shifted to higher level? in that case application layer? )
and if my above statement is correct, then what i will benefit from not using ddd and put all the effort and or (write all code) to application layer?
It seems to me that once you separate these layers (CA) (especially for large applications) and you know what ddd is, i can't think myself not doing ddd.
My reply is not about judging if using ddd is better than not doing it, but rather to understand better the differences and if any, the benefits of not using ddd. ( if any)
i also realize that i use both.
My domain layer contains, (IRepositoies, Entities with behavior (AR), some value objects, and domain services (some of them make use of repository interfaces , some other just accepting ARoots) to perform some operations or return back ARoots .
the infrastructure layer which is the implementation of my repositories and or any other technical concerns
Application layer that as you very well mention is just orchestrating and call out the domain services , or loading some AR , call some methods and persist back, Not too much logic, and if possible nothing at all in application layer.
This was one of the key points in my latest video too. This common misunderstanding is very widespread and one of the major reasons why people tend to struggle with understanding software architecture in general.
I just don't get why Infrastructure arrow is not from application to infrastructure.
If Databases are in infrastructure, wouldn't the application be the one who's calling the infrastructure?
Researching more about the matter, the arrows are not calling process, but dependency.
For implementation, Application layer could just call interfaces. Infrastructure implements those interfaces and then actually store and read data from DB.
I really like these videos because Amichai talks about the more advanced concepts that are not covered anywhere else on the internet. Because in todays market of developers, you are not getting hired with your typical self-taught You-Tube education. Your projects are going to need some complexity to showcase that you are not just some code-monkey, or react-andy. Before these videos I could not map a domain to schema, or had any idea on to create a domain to begin with. I feel like I had that level of professionalism to my projects needed to get noticed by employers. I think the only thing I have not seen on the internet is how domain events are implemented together with something like Mass Transit or RabbitMQ. Excellent explanation of how separation of concerns synergizes with battle tested patterns and architectural principals to produce quality code.
Agreed what you just said. Also, it's required to understand that DDD != CA.
I have seen people claim they have done DDD because they have implemented CA. Which is wrong.
DDD can be used to model your problem domain but it should not influence CA.
A tactical design decision tree can be used to identify business logic patterns and architecture patterns based on the subdomain identified (supporting, generic, and core)
Hello, Amichai. Do you have a special discount for a poor public school teacher from Brazil? 😊
Really good vid. However, I kinda got confused when you started talking about the Application layer. Why do you have the application layer talking to the Infra layer? I thought the application layer can only communicate with the domain layer.
As far as I know application layer orchestrate the communiticatiin between presentation layer, domain and infrastructure. But however I'm confused why he said repositories are written in application layer. Because I thought infrastructure and repositories where the same
you've been engagement'd! Loving the fresh vods lately - keep 'em coming!
I feel like this is always explained a bit differently, as originally, the domain layer would contain all interfaces and definitions, and the application layer would implement them in the usecases. so strictly speaking the business "code" is in the application, while the domain only describes, but has no logic, however sets the domain language.
From CA i am not sure that domain layer should contain logic, why is it not in application layer? as part of orchestration. In my experience, domain layer mostly contains domain entities, some constants and hmm maybe some exceptions
Thanks for your videos, Amichai.
My question will sound very specific but who knows... In my industry, experts are referring to real-world objects as "manufacturable" and "manufactured". But the current codebase refers to the corresponding entities as "manufacturableMachine" and "manufacturedMachine". Is there any recommendation on using either language in the codebase? The actual spoken terms, or more formal terms? Or if there is any kind of standard regarding this question, is it bothersome that the words used to refer to these entities are adjectives or past participles?
from your courses would u suggest viewing the DDD before the Clean Architecture?
Can you please bro do a typescript clean architecture DDD course ❤
It's the same principles, just using Typescript?
DDD is language agnostic, and the course would be very similar.
The Clean Architecture part would be implemented differently, using different libraries and tools, but would also look very similar.
Maybe in general I do think it is a good idea to port the courses to other languages as well to help viewers understand the content in their preferred language, but don't think I'll have time for it in the foreseeable future
Great content I found today
May we say that DDD, is when you develop little framework before for the specific application?
Can you issue a video code to realize the use of the warehouse layer and factory?
Good way to start the week, thanks so much!
Hey Amichai, would it be possible to share the figma files/link for the diagrams/designs you've used in your CA-template? That way we could make similar diagrams for our projects, or update the ones you've used.
Answered on GitHub, but will drop the link to the figma communite plugin here as well for anyone coming across this comment: www.figma.com/community/file/1334042945934670571/clean-architecture-project-file-system
Hey Amichai thanks for your explanation it is clear!
Many thanks for the video and expecting more :)
Great video, thanks... Smash the like button... I don't suppose you're a badminton player are you? ;)
Not at all 😂
@@amantinband :D I ask because it's a catchphrase from a badminton channel I watch ;)
3:31 to the core layer rather?
hi, is the content of the video included in one of your dometrain courses? thanks!
Hey, I don't have a section that covers specifically the difference between the two (maybe that's a good idea for future courses). I have in depth courses on both CA and DDD so I would like to believe that viewers would know the difference, but maybe a dedicated sub-section is a good idea for the future
Great video - thanks!
Clear as mud!
Thanks for the video
*PromoSM* 😈
Excellent video indeed.
Thanks! Crystal clear.
thank
God bless your heart Amichai. Struggled with the relationship between both concepts for quite a while now
Hey Amichai,
What do you think about the idea of using Clean Architecture for Modules in a Modular Monolith?
On a first glimpse it seems like a good idea, especially since the Data Access can often get messy and Data Access across different Modules is made. With one Infrastructure layer, that wouldn't seem so wrong and confusing.
Using CA with modular monoliths is very common. Regrading infra, most solutions create an infra layer per module. Shared resources would be extracted to a common project if needed, but each of the modules would have it's own ifra layer
@@amantinband thank you! The common project is a good idea. In fhe data access we have a lot of cases where many Databases are joined together in each modules data access. That's why I was thinking of one Infra