How to implement Clean Architecture in Node.js (and why it's important)
HTML-код
- Опубликовано: 7 сен 2024
- As software systems grow, they can start to become unmanageable, especially when working with teams of multiple engineers on a system planned to live for years. Following software architecture designs can help reduce this complexity by allowing you to easily swap out third party libraries and protector your business logic from being tightly coupled to these third party dependencies. You may argue tat clean architecture is overly complex and smells like over engineering, but you will more than likely need some form of software architecture standard when dealing with large code bases.
------------
🔔 Newsletter eepurl.com/hnderP
💬 Discord / discord
📁. GitHub github.com/cod...
I like this video because it’s about a specific design concept and not embedded in a massive beginner tutorial. There is not enough mid-level programming info like this. Thanks for making this and Keep it up!
Right, it's hard to find quality content for mid or advanced concepts.
This is a better tutorial on dependency injection and inversion of control than hour long lectures and videos I had to listen to on the same subject.
Clean architecture, hexagonal and Domain Driven Design are really abstract concepts. They all encapsulate some really great ideas but I also strongly believe that it's something that you shouldn't get too caught up in. Find a level of abstraction that works for you and roll with it. I went on a whole craze a couple years back designing systems with all of these concepts and even though I did build some really cool stuff, it was extremely overkill for what was actually required. Great video though as always! It would actually be really great to pick your brain sometime about some stuff! Can't wait for the next video!
You’d be surprised how empty my brain is ;). But if you have a particular topics you want me to talk about let me know
Exactly!! The point of designing software is not to use the fanciest or most complex design, it's to get the job done and have a testable, maintainable, and resilient system.
I’ve spent a lot of time trying to understand this architecture. I’m always lost when I get to the inversion of control, thanks to your video, it has reinforced my understanding of this architecture.
Would be really interesting to see how you structure folders with this approach at your job!
I would separate the routing functions into a controller folder, the buisness logic into a services folder with say "UserService", "Email service" and then database or whatever classes into a "DAO" folder (data access object)
also you would need a validation folder and provably helpers. good video here: ruclips.net/video/oNlMrpnUSFE/видео.html&ab_channel=PedroTech
@@MattBidewell this sounds like NestJS?
Finally a tutorial that actually implements clean architecture instead of talking about it. Thank you
For many years, maybe +4 years I have been working with these kinds of code architecture and patterns but I absolutely have NOOO idea what I was doing. Now you are giving me an enlightment! I know you deserve more than this, but please accept my humble subscription to your channel 🙏
thanks for the sub! I'm glad you found my content useful
Nice video!
General observation about clean architecture: I'm all for abstraction, but one has to know when to stop ;-) At some point - same as with clean code - instead of making your project more maintainable, you're creating spiderweb of dependencies (even if it's mostly just abstractions / interfaces). Then, understanding and debugging code can mean jumping through a myriad of files. It also depends largely on the size of the project. You need to understand when you should apply those concepts and when it is overkill. Always remember - YAGNI
I spent several hours struggling with the high-level description of the clean architecture diagram in the Clean Architecture book. Your explanation in the video was fantastic - it really clarified things for me. Now it all makes sense!
Great job going over the important aspect of the concept instead of living in theoryland. Definitely much harder to demo this without using typescript.
tomorrow is mine interview and i found this really helpful to explain how i have been doing previously and how this architecture could be helpful to improve further!
thanks for the video!
Woooowwww, so clear and real !!! Complete agree that all these architecture things are too-too abstract. I think that architects (and most of the times the sellers) try to think this is magic, like it happened with Agile, or OOP. Thank you man !!!
This is the far most understanding videos for people that are starting to understand the Clean Architecture concept, my sugestion would be show how folders are set-up, thanks for the video
Really well explained, they should teach this concept in each CS high school and university
Would love to see a course about this topic. 3 hour video on how to create a clean application with node, nextjs, maybe some database, everything hooked up with docker compose, testing included. Would pay serious $$$ for something in that direction.
I think this was great. I’m a sucker for code organization practices, but I haven’t looked into backend best practices until now. The examples you gave clearly illustrate the benefit and I think you have just the right amount of detail for anyone that is searching for this topic. Excited to look around your channel more. #subscribed
I don't think there's real difference between front and back end code architecture. You can apply these concepts to any codebase
Awesome video ! Very clear. It's true most speakers talks hours and hours of abstract concepts. I like how you managed it to show a real world example in 20 minutes. Thank you !
Thank you so much for this video. It was very helpful. Well explained.
Raw-dogging JS like this is hard, even with TS. Our team started using NestJS which is based on dependency injection and this philosophy. It's slightly opinionated, but takes all the guesswork out of architecture, so any newcomers to the projects intrinsically have a working knowledge of the application without looking at a single line of code.
I haven't tried nest.js yet, but it looks like a solid way to write a rest api from their docs
Very well explained. Instead of discussing abstract concepts you have covered a use case which becomes very easy to grasp the concept and much quickly. Thanks alot
Good video, with nestJs all is inside the box (Clean architecture,Separation of concerns, Dependency Injectection etc..)
Thank you so much. I really like that you show the practical side of clean architecture
Fascinating content, most clean architecture are either simple examples or written in another language thanks for clear explanation, hope to see more content about ddd and clean architecture written in typescript 🙌🏻🙏
My friend, your content is amazing and such a big help. please dont ever stop
Thanks man!
It's a nice explanation, if you could share the boiler plate code for clean architecture would be helpful. A series on clean architecture with es6 would also be helpful, Dependency injection as a topic is worth to cover.
You really nailed it! I've never understood the hexagonal architecture this much clearer. You do deserve more subscriber. Many thanks!
Thank you for the vid! Clear, straight to the point and from a perspective that is easier to grasp.
I really like this topic ! Backend and frontend (I've not yet to find a video on clean architecture with redux thought is someone has one I'd love to take a peek at how people might use it)
Very usefull, plus the actual example made everything a lot clearer than if it were just theory. ❤
Great video!
This a great example to send to junior developers
Please make a full series of nodejs. But not basics but advance like how big scaling project code works, how uber uses nodejs
Really enjoyed it. Great content. Thank You! 🙏❤
Awesome! So you're basically organizing the system into framework agnostic controllers, a service layers for business logic, and a repositories to abstract db operations-everything with dependency injection and inversion. Question I have is:
Do you like doing this at a granular level per use case. For example, create 3 three layers for each user use case, like createUser, updateUser, etc. Or do you prefer to encapsulate related functionality like having a controller, service, and repository/persistence that encapsulate all user-related operations?
Business logic is not a domain logic. Separating domain logic from business (aka application) logic is the purest form of a clean architecture also called the onion architecture. The thing which you are calling "businesses logic" is the "application business rules" in the clean architecture picture. But great video in general showing the whole idea in a clear way.
Helpful intro to the topic. Much appreciated.
good video, would be great if you had some kind of a series about architecture in general
This video is very helpful!!
Hope you can give more concrete examples to help us understand the architecture more.
Thanks again!
I finally understood the dp injection thank you
outline: The speaker explains hexagonal architecture, also known as ports and adapters, and how it is used to protect business logic from changes in external sources. This architecture is beneficial in simplifying future changes to external dependencies, such as switching from MySQL to MongoDB. The speaker uses a pseudocode example of an Express app to demonstrate how to apply clean architecture, which involves decoupling business logic from external sources. The speaker emphasizes the importance of defining interfaces to pass in real implementations and avoiding tightly coupling to third-party dependencies or frameworks. The example includes removing Express-related code from the business function and creating a new file for database persistence.
The speaker explains the implementation of clean architecture, which separates business functions from third-party dependencies. They show how to use dependency injection to achieve this, without getting caught in abstract concepts. They highlight the use of entities, which contain business rules and logic, and can be validated before being saved to the database. By using clean architecture and entities, the speaker suggests it is possible to structure code effectively and ensure it meets criteria. They advise viewers to use a framework or library to help with implementation.
Made with chat gpt?
Im still seeking those concrete examples because I am having trouble wrapping my brain around like what is the domain layer what is the business layer ( working in next now ) Hoping this clears things up more
Clean Architecture has been going out of favour in the .Net world for a few key reasons. It requires a lot of code duplication and mapping to communicate between layers; functionality is hard to find because of abstract structuring; the previous two make refactoring extremely time consuming and tedious. A better architecture is vertical slices.
So part of the front end learning process, we do things like create json files with constants of various data, example a lot of portfolios essentially have a json resume that get mapped across the application in various ways.
Would you say its safe to think of using this practice over having a big chunk of json at the top of the code that uses as the most micro implementation of clean arch? I see it as at least to a degree the code mapping the data in the portfolio has no knowledge ( or concern ) aside from the import of a json file or how the data is stored the code just gets data from else where. I have also gone through old projects built liked this and upgraded them to use a database with out having to change the presentation logic. of course even something that small could be broken down more like a pseduo DTO between the 2 or something.
But I am just trying to see if i can think small and step my way up to a bigger understanding.
Great video. Learned function injection. Thanks!
Probably it is all about dependency inversion principal you’ve told in this video. And this is only one part of Clean Architecture, like in-out ports
It’s hard to do true CA with a dynamically typed language. Something like typescript could setup interfaces for the ports, but js doesn’t support explicit interfaces; all interfaces are implicit. So the in port to the interactor is just the arguments passed in and the out port is what is returned
Thanks dude this is an eye opener.
My 2c's:
Clean architectural pattern works if you know your business logic; said differently: it's a good choice when starting a project based on an existing product.
Swapping out the database isn't something teams tend to do often--usually at the very early prototype stages, OR when sunsetting an MVP and moving to vNext.
If entities implement enterprise logic (and typically requires persisting to a database), where should that logic live? Relationships between entities is often a function of foreign-key relationships across database tables. Does that then mean all enteprise logic lives in the database? Does that then mean enterprise logic by definition is only the type of logic that can be enforced by the database engine?
I would keep all business logic out of the database. It’s ok to have some basic data integrity checks on your columns, but your code entities should verify a string field is an actual email, or an age isn’t negative and isn’t greater than 200, etc
Thank you, Keep the good work!
this video makes me subscribe
Supet great and understandable!! Huge thanks 🙏🏻
This is how those things should be explained
use cases are objects with their own request and and response objects
Hi there mate, thanks for this video. I am subscribing and hope you can dive deeper into this topic with maybe showcasing a small project with MongoDB and how this can be implemented. Great work though
what is the best naming conventions? can you give us a repo we can refer?
Thank you so much 🙏
The separation between the Infrastructure and Interface Adapters layers is unclear to me. In which layer does createUserPersistence.js belong. It directly uses the database, which is infrastructure. So it can't be part of the Interface Adapters layer as it is not allowed to access the Infrastructure layer. But what is inside the Interface Adapters layer then?
FANTASTIC video. ThaNk you.
This could be also done with CQRS pattern, i find it pretty convenient
Great explanation, thank you!
This is gold
This is amazing, thank you, if I wanted to use zod or joi for the validation how would I do it without actually requiring or importing the packages in the entities layer as those packages belong in the outer most ring?
very good video for get a little close to the CA. Maybe if you can do a next video showing like, the adaptor. So if for example i want to change between mysql to postgress, i dont need to change nothing inside the code besides the caller.
Thank you!
The useCase should be able to call the same methods used to get data from the database. You should be able to just swap out the persistence methods at the higher level
Regardless of the abstraction, any non trivial app is going to be hell to migrate from mysql to mongo or vice versa
@webDevCody, i was wondering if you need interns in you work place. I would break a leg just to be mentored by you. You inspire me a lot.
Excellent video. Btw, which VS Code theme is this?
In what world switching from MySQL to MongoDB would take one line of code? They would not even have the same ORM layer. It will only be partially possible when using an ORM layer that supports the same type of DB as you want to swap and that also would be 80% coverage as for any nontrivial application, some queries will be written raw. - Just dropping this in here so someone wont get over sold or x or y architecture.
The point is your business logic is decoupled from the code that accesses the database and those database access methods are injected as dependencies meaning you can potentially switch certain parts of your data models from one database to another. Your ORM would live in a persistence layer, it wouldn’t be one line so sorry if I said something dumb like that. The point was to make the code more decoupled and easier to refactor in the future
bro.. i love you thanks for the video
this video is really helpful!
Amazing explanation ! Got my sub !! :) Do you have any tutorials or videos where you speak about DTOs? (Data Transfer Object)
I'd love to hear more about this.. :)
Not really, I have a recent video about clean arch but I don’t often use dots
Where will you put validation for Entity foreign key or Entity unique. Is it domain layer validation or iteration layer validation?
Great video, thanks.
Clean architecture is yechnically not an architecture. There is a reason that you cannot find a proper example by uncle bob himself. Its simply onion architecture with a few added principles.
You missed the fact that dtos play a very important role since technically you are still coupled.
I kind of dislike that people mention decoupling for ease of switching stuff because it barely happens... the biggest win imo is testability.
Overall a great introduction to tease people their brains! We should collab someday.
Thanks for the comment! I think it’s good for both unit testing and swapping out modules in integration tests. Often when dealing with AWS there are a lot of services we interact with, so when running out integration tests in CI/CD or locally, we want to swap out the implementations to save files to local s3 mock services, mock dynamodb services etc. clean arch helps. But you’re right, often we don’t care to swap out our databases in the future.
When you say dto, are you referring to the data Id be sending to the repository layer? Like in my example, createUserPersustence technically shouldn’t be passed the UserEntity, but instead a subset of necessary properties. But everything in JavaScript is an implied interface so it doesn’t matter too much as long as the object passed has the necessary properties on it.
Send me any resource you have related to DTO. I think we might call the serializers or deserializers in our project. The things you run yours data through before you send it back from the API to the UI right?
@@WebDevCody Hey 👋
Technically a repository is supposed to get the domain entity and from there on map it to a model that it needs to persist it to the database, so that part is completely fine! What I'm referring to is that you are using POJOs (simple objects) and just passing it the data, instead, it should be a DTO imho.
Having a DTO makes it that an interactor doesn't have to know about the mapping, and gives the user / dev a contract to work with which allows for independence. I guess for sending an email you probably would create a factory E.g. emailFactory.createEmailResponse(User) which would return you a dto to pass to the email service.
Khalil has very good stuff:
khalilstemmler.com/articles/typescript-domain-driven-design/repository-dto-mapper/
he's also in the middle of writing a book called "SOLID" not to mistake with the famous principles, its not done yet but it's to a point where it's worth a read. Anyway, mad respect for doing this kind of vids man! More developers need to get into this.
edit:
Should mention, after all its about trade-offs anyway. In a real world app we just pass a dto from controller to the repo and dont even care about entities because the amount of domain logic or need for completely being decoupled is not there.
one of my projects that I stopped working on:
github.com/donnyroufs/cofey/tree/develop/libs
@@donnyroufs551 Im not sure if I’m fully understanding. I could see the value when making a public api and you don’t have access to the clients consuming your api. In that case you’d want a contract to prevent your consumers to get changed data. (Unit and integration, or contract testing can verify this). On the project I’m on, if we update our entity, we also just go into the UI code and updates whatever might have changed. Usually the most that has changed is we added an additional property to an entity, so we don’t care if the ui is coupled to the api response because it’s just additional data coming back. I don’t see a value just yet for using a DTO between the business layer and persistence layer (or email function like you mentioned). The function is defined via an interface so the arguments are already coded to a contract.
But yes, I agree most of all of this is a trade off. Adding all this “clean” design and abstraction makes the code a lot more complex to understand. We as engineers just need to know the pro and cons and apply these principles where we think they’d work best
@@WebDevCody Well a DTO is not just for your infra layer, it's to make sure you decouple layers and to move mapping to another place. Having a simple dto at controller level isnt enough if you want proper versioning either.
Amazing explanation!! Very Simple to understand and very straight forward!!
thanks
i think beginners should start with nest js ... it's hard for them to apply clean architecture in express and nest js forces them to do it
This is really informative, thank you! Quick question: what are some other benefits of implementing this kind of architecture apart from being able to easily swap out implementations? I'd like to advocate for this at my company but I don't feel like I have a strong enough argument to really vouch for it.
It can help with testing since it’s easier to mock out dependencies that are passed in instead of relying on a mocking library to achieve that. It also keeps the code base organized so all business logic exists in a similar place instead of it being sprinkled all throughout your code base. It takes discipline to double check you’re adding code to the correct layers.
Yeah testing is a big one. I've actually learned about dependency injection when we were trying to prevent tight coupling between classes so that each class can have its own unit tests written separately. That was why I understood the clean architecture approach that this video takes to dependency injection/inversion of control.
Pure gold.
I wanna try to do this with nest.js, I'm gonna use repository interface and have a repository class that implements that interface and uses typeorm, then for inside my service class I inject that repository by the interface, then later I can switch out the orm with another orm if I need too or use both it dont matter
The one thing I am afraid of it is that code perfomance will be slower
It’s fine
wow, amazing!
Thanks a lot !
Great example!
Can you publish the code? Tks!
Would be great to know clean architecture in React app since its so unopinionated
Hi! I would ask if you don't think we can catch validation error before in some middleware. I use express-openapi and works very good.
You could do that, but I do think validation should be as close to your business entity as possible. It’s probably safe to validate the payload coming in, then also validate the entities as you change their properties
I need that theme!!!
Excellent.
thanks bro 🙏, any link on github for code in this video ?
What theme are you using for the text editor
Bearded theme stained blue
Good job babe!!
@ what are you using for code completion? Your autocomplete plugins are way too far from what standard intellisense can offer
Probably copilot?
@@WebDevCody nice, thank you, never saw it at work
get you share source code in github?
F*ing good. Do you have anything on clean architecture folder structure for small / mid / about to scale projects ? tthanks
Not at the moment, I need to make a starter repo
@@WebDevCody looking forward. By the way - why do you have "require" instead of "import" - do you use older versions of node for a reason ? Also i found very little amount of tutorials on project structure when you have both static pages and API in one project.... might be interesting for you next tutor. Thanks!
Muito bom 🇧🇷
if I would to do this pattern!, I will keep them all in the same file.
can u update this concept but with using prisma? :)
Uncle Bob === Robert Martin (why not just Uncle Rob?)😅
I have question, what if i want to validate if the user exist from database before calling a post request? how and where i can put the code, since in user entity it has validation without db code stuff.
I wonder if its good to validate if user exist in createuserpersistence like this? hope it make sense.
connection.query("SELECT * FROM users WHERE psid = '"+ psid +"'", (err : any, res : any) => {
if(res.length === 0){
// connection.query(`INSERT INTO users ....
}
})
I’d make a persistence method called getUser and you’d call it from the interactor. If getUser returns null, you can call the createUser persistence method. If the user exists, have the interactor throw an exception and your api layer would catch and return a 4xx status code
@@WebDevCody Got it. btw thank you for this awesome content. Also for your quick response. Appreciated
@@WebDevCody
i dont know if its good to pass the res and getUser persistence to validate and send status in user entity. is it okay or bad?
// user interactor
await user.validate(getUserPersistence, res);
const newUser = await createUserPersistence(user)
return newUser
// user entity
async validate(getUserPersistence : any, res: any){
const user: any = await getUserPersistence({psid: this.psid})
if (user.length) {
return res.status(409).send('User already Exist')
} else if (!this.psid || !this.name || !this.email){
return res.status(409).send('Improper Values')
} else {
return this;
}
}
@@jggabayno the interactor should not know about res at all. Also, I wouldn’t have your entity call the persistence method. Take the data returned from getUser and construct a new user entity using it, then validate the user entity
Join my discord for more help
Hi,Can you build a beginner tutorial of this?
Maybe if I have time
I can't find the repo link
Okay but why on earth are you still using require and not import 🤨
ive never done this