I would recommend to keep express types out of controllers for the sake of clean architecture. In theory, the controllers should not depend on utilities such as express. A way to do this would be implementing an interceptor to convert express requests to relevant stuff such as URL parameters, request body, queries, and authorization headers (or any other headers) so that if you decide not to use express in the future, you can only edit the ApiServer class and be done with it.
Yes I'm with you. This is also what I used to do but if we are pragmatic about it then the amount of effort it costs to decouple yourself from such frameworks doesn't seem to be worth it for your average application. Which is probably also the reason why we dont see this done often if at all in publically available source code. This is also the reason why I instead aimed on the minimal amount of effort to decouple the application layer from the infra layer(with the focus around your traditional picked http driver) Which again isnt the traditional take of CA hence I explcitly called it the "modern" take. Though in hindsight I should have added another slide on this considering it gives you the tools to truly decouple from such frameworks with ease of plugability. Edit: Also, it adds even more work when you use the likes of decorator based frameworks considering ts is lacking in that department.
Given the controllers don't do much, you can move DTOs to the application layer (which is fine according to some DDD people) and turn controllers into universal wrapper around use cases which let's say always reads request body and pass it as a UseCase input and returns UseCase output as a response body. In this case all the express code will be in one controller file
Keep these videos going man, they are great. Can't really find recent content like this elsewhere. Wouldn't mind paying for a full course either with a production level project.
@@ruslan_yefimov Definitely a reason why I don't make courses. RUclips is in between where I consider it okay to share my thoughts and experiences but a course is something you pay money for, and if I cannot be sure that what I'm saying is "correct" then I don't feel like doing it. I even hold back on youtube videos because I want to experience anything I "teach" myself for a good amount of time. There is an upcoming video about testing that should hit somewhere this year though :D
Nice one, man! I liked at the end where you get to see everything all linked up. Clean Arch is so good for finally forcing you to think about the abstractions you're creating instead of just writing code 'till stuff works. Would love to see a composition or DI container video as a follow up - curious how you prefer to link things together for flexibility.
Yeah, pretty cool video! Thanks! What if you need to use "use cases" in several places though? Or when a second "use case" depends on the result which we receive from the first "use case"? For example: I need to send an invite after placing the order, or just send an invite and create a user immediately. Creating user - it is "use case" (you can create a user as an admin, or as a user who comes to the website) Sending invite - use case Placing an order - "use case"
You can inject these use cases and use them, pipe them together or utilize an event bus. Sending an invite to me is a side effect so that's always done through an event if its on me. Placing an order can also be done through events if you want to loosely couple it. Ofcourse it always depends I don't know the context. If ordering and creating a user are both in a different domain then definitely events.
This is one of the best technical RUclips videos I've ever seen. You cited sources, covered the facts and then separately expounded on your opinion followed by an actual live-coded example beyond "products," "orders" and "customers." Very well done, you've earned my subscription.
Hey, nice tutorial! Thanks for the content... @donnyroufs551 I have a confusion, maybe a silly one... From my understanding, you used DTO classes (instead of the domain entity Logbook) to decouple the presentation layer from the domain and application layer, right? However, the infrastructure layer repo classes use the domain entity (Logbook). Then, how does the clean architecture help us separate the domain layer from the infrastructure layer? What am I missing? I'd really appreciate your response explaining this to me. This is probably the only big confusion that I have regarding CA. TIA...
Suppose that you have a project with hundreds of features, and you implement the repositories with MySQL. What about if one day you need to move to MongoDB? You are in trouble because you need to modify every repository in hundreds of different feature folders, instead of modifying them in a single root folder like the architecture one. So vertical slicing is good from one point of view, but is bad from another, as the layered pattern (don't confuse with clean architecture, because it doesn't force you to structure the project in a layered style)
You can push your infra concerns out of the feature and just expose an interface. Then in a shared kernel you can implement that interface e.g. have 1 big repository for mysql and 1 for mongodb implementing these interfaces. Then you can inject said repository.
@@donnyroufs551 Yes, but you still have different folders for the same feature, so it's not more vertical slicing architecture, since it forces you to group all feature related things within the same module/folder
@@donnyroufs551 Yes, moreover, if you consider controllers/handlers you should also create additional interfaces if you want to move them outside the feature folder, besides they are not so useful and can be usually avoided
0:0: Intro 0:17 : What do you need to know ? 0:30 : Before we get started 1:40 : Agenda 2:08 : Dependency Inversion Principle (DIP) 4:40 : Interface Adapter 6:25 : The Modern Take 10:45 : Main Component
I would love to see another tutorial where you build vertical slice architecture from scratch. Either way, this was great and you got a subscription from me. Thank you
Damn this is difficult as a junior dev :((, but thanks :D. Do you have any suggestions/resources so someone with less context to polish on these concepts?
You can read the article written by the author himself on clean architecture but beyond that I dont have any specific resources. Github code search is always a gold mine.
Hi Donny thank you for creating this video it was very useful, I had question or something to clarify, with. if I had to communicate with other services by hit their endpoint where i should put the execution of it? in my understanding it will be on the infrastructure layer CMIIW thanks
Yeah that's correct. Don't know your use case and requirements but we commonly use messaging systems to communicate between services. For example, a payment gets made, so we emit an event to our message broker -- and the service responsible for sending emails picks this up.
Thank you for the great video. I'm interested in your opinion on the thought that adding a new logbook looks like a business action and should be included to the domain model. In this case we could have corresponding Domain Service or LogbookStorage Aggregate which uses repository and thus repository interface migrates to the domain layer. The more or less complex domain logic should have access to the repository anyway.
Hi Donny, Thanks a lot for sharing such valuable insights. Your content is a goldmine of knowledge, and I can't wait to apply these learnings. Keep up the fantastic work! 👏👍 Question : I need to integrate a 3rd-party service like Stripe and also utilize some AWS services. Could you please guide me on how to align these requirements with the project structure you have suggested here. Thanks
Create an interface in your application layer and implement it in the infrastructure. Make sure that your interface has its own types. It's okay to name it specific to the service you are using or to be compeltely generic. It's up to you.
Putting the type of the variable into its name (e.g. starting interface identifiers with an "I") is called the Hungarian notation and it has been mostly discouraged for quite a long time. Even Uncle Bob writes about it in his "Clean Code".
![Cody Johnson - I'm Gonna Love You (with Carrie Underwood) [Official Music Video]](http://i.ytimg.com/vi/yy9PuYMU29g/mqdefault.jpg)
I would recommend to keep express types out of controllers for the sake of clean architecture. In theory, the controllers should not depend on utilities such as express. A way to do this would be implementing an interceptor to convert express requests to relevant stuff such as URL parameters, request body, queries, and authorization headers (or any other headers) so that if you decide not to use express in the future, you can only edit the ApiServer class and be done with it.
Yes I'm with you. This is also what I used to do but if we are pragmatic about it then the amount of effort it costs to decouple yourself from such frameworks doesn't seem to be worth it for your average application. Which is probably also the reason why we dont see this done often if at all in publically available source code.
This is also the reason why I instead aimed on the minimal amount of effort to decouple the application layer from the infra layer(with the focus around your traditional picked http driver) Which again isnt the traditional take of CA hence I explcitly called it the "modern" take.
Though in hindsight I should have added another slide on this considering it gives you the tools to truly decouple from such frameworks with ease of plugability.
Edit:
Also, it adds even more work when you use the likes of decorator based frameworks considering ts is lacking in that department.
Given the controllers don't do much, you can move DTOs to the application layer (which is fine according to some DDD people) and turn controllers into universal wrapper around use cases which let's say always reads request body and pass it as a UseCase input and returns UseCase output as a response body. In this case all the express code will be in one controller file
I've been studying CA for the last month and am finally at the point of implementing it. This video is tremendously helpful. +1 Sub.
Keep these videos going man, they are great. Can't really find recent content like this elsewhere. Wouldn't mind paying for a full course either with a production level project.
I'd love to see this a year ago.. Even though he's not right at everything, general concepts are all very well explained - very useful
@@ruslan_yefimov Definitely a reason why I don't make courses. RUclips is in between where I consider it okay to share my thoughts and experiences but a course is something you pay money for, and if I cannot be sure that what I'm saying is "correct" then I don't feel like doing it. I even hold back on youtube videos because I want to experience anything I "teach" myself for a good amount of time. There is an upcoming video about testing that should hit somewhere this year though :D
Nice one, man! I liked at the end where you get to see everything all linked up. Clean Arch is so good for finally forcing you to think about the abstractions you're creating instead of just writing code 'till stuff works. Would love to see a composition or DI container video as a follow up - curious how you prefer to link things together for flexibility.
Nice work man. It was very clear and clean explain. Thanks for good content.
Keep the great work , it was one of the best explanation so far on youtube
Yeah, pretty cool video! Thanks!
What if you need to use "use cases" in several places though? Or when a second "use case" depends on the result which we receive from the first "use case"?
For example: I need to send an invite after placing the order, or just send an invite and create a user immediately.
Creating user - it is "use case" (you can create a user as an admin, or as a user who comes to the website)
Sending invite - use case
Placing an order - "use case"
You can inject these use cases and use them, pipe them together or utilize an event bus. Sending an invite to me is a side effect so that's always done through an event if its on me. Placing an order can also be done through events if you want to loosely couple it. Ofcourse it always depends I don't know the context. If ordering and creating a user are both in a different domain then definitely events.
This is one of the best technical RUclips videos I've ever seen. You cited sources, covered the facts and then separately expounded on your opinion followed by an actual live-coded example beyond "products," "orders" and "customers." Very well done, you've earned my subscription.
Hey, nice tutorial! Thanks for the content... @donnyroufs551
I have a confusion, maybe a silly one... From my understanding, you used DTO classes (instead of the domain entity Logbook) to decouple the presentation layer from the domain and application layer, right? However, the infrastructure layer repo classes use the domain entity (Logbook). Then, how does the clean architecture help us separate the domain layer from the infrastructure layer? What am I missing?
I'd really appreciate your response explaining this to me. This is probably the only big confusion that I have regarding CA.
TIA...
just hit a subscribe button
You deserve it
Suppose that you have a project with hundreds of features, and you implement the repositories with MySQL. What about if one day you need to move to MongoDB? You are in trouble because you need to modify every repository in hundreds of different feature folders, instead of modifying them in a single root folder like the architecture one. So vertical slicing is good from one point of view, but is bad from another, as the layered pattern (don't confuse with clean architecture, because it doesn't force you to structure the project in a layered style)
You can push your infra concerns out of the feature and just expose an interface. Then in a shared kernel you can implement that interface e.g. have 1 big repository for mysql and 1 for mongodb implementing these interfaces. Then you can inject said repository.
@@donnyroufs551 Yes, but you still have different folders for the same feature, so it's not more vertical slicing architecture, since it forces you to group all feature related things within the same module/folder
@@LukeTubex I'm not sure what you are getting at? Are you saying that if the implementation lives outside of the "feature" that it isn't perse, VSA?
@@donnyroufs551 Yes, moreover, if you consider controllers/handlers you should also create additional interfaces if you want to move them outside the feature folder, besides they are not so useful and can be usually avoided
Clean Architecture is wrong
0:0: Intro
0:17 : What do you need to know ?
0:30 : Before we get started
1:40 : Agenda
2:08 : Dependency Inversion Principle (DIP)
4:40 : Interface Adapter
6:25 : The Modern Take
10:45 : Main Component
Such a brilliant video. THANK YOU. Finally was able to implement CA step by step with no issues other than package versions.
I would love to see another tutorial where you build vertical slice architecture from scratch. Either way, this was great and you got a subscription from me. Thank you
Damn this is difficult as a junior dev :((, but thanks :D.
Do you have any suggestions/resources so someone with less context to polish on these concepts?
You can read the article written by the author himself on clean architecture but beyond that I dont have any specific resources. Github code search is always a gold mine.
Hi Donny thank you for creating this video it was very useful,
I had question or something to clarify, with. if I had to communicate with other services by hit their endpoint where i should put the execution of it? in my understanding it will be on the infrastructure layer CMIIW
thanks
Yeah that's correct. Don't know your use case and requirements but we commonly use messaging systems to communicate between services. For example, a payment gets made, so we emit an event to our message broker -- and the service responsible for sending emails picks this up.
Are you using noise suppresion? Voice seems off because it slides off to nothingness at the end of the words.
Yeah... I had it a tad too high. It seemed to cut off when I moved away from the mic. Definitely something I need to test properly the next time 😅
@@donnyroufs551don't stress on it it's a type of thing where you become good with time only.
yoo very helpful video!
btw can i ask what theme and font are you using ?
Can't recall the theme. Font is Dank Mono with some slight customization, line height is around 2~
awesome ❤
how can we use websockets in this architecture??
@@VK-xw9mm you replace the http controller with whatever you use to establish the webhook. Anything in specific?
Thank you for the great video. I'm interested in your opinion on the thought that adding a new logbook looks like a business action and should be included to the domain model. In this case we could have corresponding Domain Service or LogbookStorage Aggregate which uses repository and thus repository interface migrates to the domain layer. The more or less complex domain logic should have access to the repository anyway.
Awesome video! You captured so much knowledge into a 1 hour video.
Hi, bro. Finally, new video ))
Hi Donny,
Thanks a lot for sharing such valuable insights. Your content is a goldmine of knowledge, and I can't wait to apply these learnings. Keep up the fantastic work! 👏👍
Question : I need to integrate a 3rd-party service like Stripe and also utilize some AWS services. Could you please guide me on how to align these requirements with the project structure you have suggested here.
Thanks
Create an interface in your application layer and implement it in the infrastructure. Make sure that your interface has its own types. It's okay to name it specific to the service you are using or to be compeltely generic. It's up to you.
Putting the type of the variable into its name (e.g. starting interface identifiers with an "I") is called the Hungarian notation and it has been mostly discouraged for quite a long time. Even Uncle Bob writes about it in his "Clean Code".
That's the thing, what works for one, doesn't work for another. I prefer to prefix interfaces, others don't. Pick your poison