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!

@waelgh4307

Жыл бұрын

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!

@WebDevCody

2 жыл бұрын

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

@exe2543

9 ай бұрын

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.

You really nailed it! I've never understood the hexagonal architecture this much clearer. You do deserve more subscriber. Many thanks!

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!

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 !

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!

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

@hojdog

Жыл бұрын

I don't think there's real difference between front and back end code architecture. You can apply these concepts to any codebase

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 🙌🏻🙏

Would be really interesting to see how you structure folders with this approach at your job!

@MattBidewell

Жыл бұрын

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)

@tonienguix6503

Жыл бұрын

also you would need a validation folder and provably helpers. good video here: kzread.info/dash/bejne/oYKgr9Spnri5dqg.html&ab_channel=PedroTech

@naughtiousmaximus7853

5 ай бұрын

​@@MattBidewell this sounds like NestJS?

Helpful intro to the topic. Much appreciated.

Thank you so much. I really like that you show the practical side of clean architecture

My friend, your content is amazing and such a big help. please dont ever stop

@WebDevCody

2 жыл бұрын

Thanks man!

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 🙏

@WebDevCody

Жыл бұрын

thanks for the sub! I'm glad you found my content useful

Really well explained, they should teach this concept in each CS high school and university

Thank you for the vid! Clear, straight to the point and from a perspective that is easier to grasp.

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

Really enjoyed it. Great content. Thank You! 🙏❤

This video is very helpful!! Hope you can give more concrete examples to help us understand the architecture more. Thanks again!

Thank you so much for this video. It was very helpful. Well explained.

Supet great and understandable!! Huge thanks 🙏🏻

Great job going over the important aspect of the concept instead of living in theoryland. Definitely much harder to demo this without using typescript.

Very usefull, plus the actual example made everything a lot clearer than if it were just theory. ❤

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 !!!

Great video! This a great example to send to junior developers

Thanks dude this is an eye opener.

Great explanation, thank you!

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.

Thank you, Keep the good work!

Great video. Learned function injection. Thanks!

FANTASTIC video. ThaNk you.

good video, would be great if you had some kind of a series about architecture in general

Great video, thanks.

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.

this video is really helpful!

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?

bro.. i love you thanks for the video

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)

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

Good video, with nestJs all is inside the box (Clean architecture,Separation of concerns, Dependency Injectection etc..)

I finally understood the dp injection thank you

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

Good job babe!!

Excellent video. Btw, which VS Code theme is this?

Thanks a lot !

wow, amazing!

this video makes me subscribe

Pure gold.

thanks bro 🙏, any link on github for code in this video ?

This is gold

Amazing explanation!! Very Simple to understand and very straight forward!!

Where will you put validation for Entity foreign key or Entity unique. Is it domain layer validation or iteration layer validation?

Excellent.

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.

@WebDevCody

2 жыл бұрын

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

Please make a full series of nodejs. But not basics but advance like how big scaling project code works, how uber uses nodejs

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.

@WebDevCody

10 ай бұрын

I haven't tried nest.js yet, but it looks like a solid way to write a rest api from their docs

what is the best naming conventions? can you give us a repo we can refer?

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.. :)

@WebDevCody

Жыл бұрын

Not really, I have a recent video about clean arch but I don’t often use dots

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!

@WebDevCody

2 жыл бұрын

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

get you share source code in github?

What theme are you using for the text editor

@WebDevCody

8 ай бұрын

Bearded theme stained blue

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.

@WebDevCody

2 жыл бұрын

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.

@Ahmad-ww4ue

2 жыл бұрын

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.

Muito bom 🇧🇷

I need that theme!!!

Great example! Can you publish the code? Tks!

I can't find the repo link

thanks

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?

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?

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

can u update this concept but with using prisma? :)

F*ing good. Do you have anything on clean architecture folder structure for small / mid / about to scale projects ? tthanks

@WebDevCody

Жыл бұрын

Not at the moment, I need to make a starter repo

@andriisukhariev

Жыл бұрын

​@@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!

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 .... } })

@WebDevCody

2 жыл бұрын

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

@jggabayno

2 жыл бұрын

@@WebDevCody Got it. btw thank you for this awesome content. Also for your quick response. Appreciated

@jggabayno

2 жыл бұрын

@@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; } }

@WebDevCody

2 жыл бұрын

@@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

@WebDevCody

2 жыл бұрын

Join my discord for more help

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

@WebDevCody

2 жыл бұрын

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

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?

@WebDevCody

9 ай бұрын

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

@ what are you using for code completion? Your autocomplete plugins are way too far from what standard intellisense can offer

@WebDevCody

Жыл бұрын

Probably copilot?

@qwertyntarantino1937

Жыл бұрын

@@WebDevCody nice, thank you, never saw it at work

Would be great to know clean architecture in React app since its so unopinionated

This is how those things should be explained

Regardless of the abstraction, any non trivial app is going to be hell to migrate from mysql to mongo or vice versa

Hi,Can you build a beginner tutorial of this?

@WebDevCody

Жыл бұрын

Maybe if I have time

This could be also done with CQRS pattern, i find it pretty convenient

@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.

use cases are objects with their own request and and response objects

In your experience is it worth it?

@WebDevCody

2 жыл бұрын

I think at least keeping your code split into separate layers and the dependency inversion / injection can help keep your project more maintainable and easier to test.

ive never done this

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.

@WebDevCody

Жыл бұрын

Made with chat gpt?

The one thing I am afraid of it is that code perfomance will be slower

@WebDevCody

Жыл бұрын

It’s fine

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

if I would to do this pattern!, I will keep them all in the same file.

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.

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.

@WebDevCody

Жыл бұрын

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

Uncle Bob === Robert Martin (why not just Uncle Rob?)😅

So basically clean architecture is like little apis calling little apis inside a big api.

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.

@WebDevCody

2 жыл бұрын

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?

@donnyroufs551

2 жыл бұрын

@@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

@WebDevCody

2 жыл бұрын

@@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

@donnyroufs551

2 жыл бұрын

@@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.

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.

Looks similar like repository pattern🤔

Okay but why on earth are you still using require and not import 🤨

Great video, but not so far from what you criticize in the beginning. Every single video on this topic turn around the same things "abstract", "here is the theory", "oh here is some (a lot of) code i already wrote, im gonna create a new file to make the project clean. and blabla theory", and you show up some code, but "oh i m not gonna run this. This is pseudo" but when someone will drop a full walkthrought with a real app (even just a simple CRUD) but from scratch, and show the whole project from the very begining to the execution ?

@WebDevCody

Жыл бұрын

sorry to disappoint with this video.

@shuruzer

Жыл бұрын

@@WebDevCody it is still helpful for mid/confirmed devs, but its kinda frustrating when i think about headaches my beginner self from past years had when trying to create a simple project using this architecture because there was no real walkthrough, like from "npm init". If you can do this, iam sure it'll help someone or two 😏

Excellent video. Next time just speak a little slower for non-native speakers of your language.