I'm not sure about writing 8 tests at the beginning. TDD cycle tells us to write one failing test, pass it, refactor it, and there goes the cycle. 8 Failing tests is... idk
Thanks for taking the time to watch and provide some feedback. I'm not advocating 8 failing tests. I'm using "skipped" tests as a kind of "todo list". I only unskip/enable 1 test at a time and proceed with the cycle as you described. But it's purely a preference thing, when I'm working on a feature i like having a running todo list expressed this way, it may not be everyone's cup of tea though. Thanks again for watching!
Yes. I mainly use Typescript now. I also use Zod quite a bit (behind an adapter). For APIs, I tend to generate the route handlers and types, but I treat those as DTOs and still maintain my own internal representations.
Wikipedia explains it well: “A method stub or simply stub in software development is a piece of code used to stand in for some other programming functionality. A stub may simulate the behavior of existing code or be a temporary substitute for yet-to-be-developed code.“
Thanks a million for this video!! I've read the Clean Architecture by Robert Martin, but could not understand how to apply the provided circular diagram in practice. Frankly speaking, I understand only 20-30% of what is going on in the video because of the lack of knowledge and experience, but it fires an awesome feeling of curiosity and desire to continue enhance my skills to become more and more professional as time goes by. UPD: I'm having so much emotions and insights watching this video so that I will download this video and keep it on my external drive for future reviews!! (if this video will accidentally disappear from RU-vid)🙂
gone through the code base. factories confuses me so much. so many factories in code. very hard to understand. but architecture wise very well explained🔥
wow...me watching this 4 years later is the cleanest explanation of clean architecture and dependency injection I have come across. That's some solid content you've shared. Thanks mate :)
Love what you did with the video man, and also a very clever way to implement the adapter pattern for the sanitize library, the only thing that I would change, is that I prefer to have individual files for all the dependencies with their adapters, instead of having just one big file with all the third party and factory functions. But this video is a must see! thank you
This amazing, thank you so much. Best video I have come across that implements this so well. Subscribed and looking forward to more content. I do have some questions though, if I wanted to validate the request body using a package like zod or joi, 1. would I do this in the entities layer or the controller layer? 2. from my understanding, I would need an interface in whatever layer I use this instead of the actual package and pass that as a dependency, is this correct?
I hear you ... this video was made before dark mode was as ubiquitous as it is now. Please accept my deepest apologies for scorching your retinas, my friend.
9:48 what you said here is completely backwards. The DB layer is very unlikely to change, but the entities and usecases and likely to change all the time. That's what application development is all about: you're changing the way the application works. The DB is just a set of functions you can to store/load/query the data. The DB itself will likely not change at all. And, if it does change, it's unlikely that you can just keep the rest of the code as-is. This is a pipe-dream that never materializes in reality. The DB forces you to think and structure your data in a certain way. If you use a relational database, you are _forced_ to think about your data as relational tables with rows and columns and foreign keys. This will affect how you decide to model your entities. The reason you have your comment id as a string uuid is probably greatly influenced by your use of mongodb. If you were using a relational database, you could have very likely decided to put a numeric type for the comment id.
Thank you for your feedback. It seems like we have different perspectives, which might be because we work on different types of systems. The systems I usually work on are designed to last for 15-20 years or longer. During that time, technology advances much more quickly than the entities and use cases. When you automate and enable business processes, these processes do evolve, but not as quickly as technology does. The basic principles usually remain unchanged. Furthermore, at the database layer, there are often many changes, such as moving from a custom database to an API for a commercial off-the-shelf or software-as-a-service solution, and then back to a database. Some organizations can afford to rewrite everything every 3-5 years. So, for them, the patterns discussed in the video may be less important. Regarding IDs, it's never a good idea to use numeric sequential IDs as your primary key, no matter what database technology you choose. Doing so can cause a lot of issues when migrating or integrating at the data layer or scaling to large distributed systems. It's also not a good idea to let the database generate the ID for you, as databases are meant for storing data, not creating it.
the only thing missing is how to deal with transaction or optimistic locking in a clean architecture, Do you have any examples of this say like a bank system ?
Hello Bill, I just wanted to thank you wholehearthly for this content. It really helped me to wrap my head around all this system design jargon and navigate through the plethora of clickbaity articles and videos. Have a great day.
Man your videos are Awesome, they talk about the real stuff that nobody else talks about, keep going. I am so glad I found your channel and I will be watching as much of your videos as I can
This is very much an object oriented style, it's just not using classes, or the class keyword. If you prefer to use classes in your javascript you can now achieve the same thing thanks to the introduction of private fields in JavaScript classes.
Liked and subscribed. This architecture is the real meaning of plug and play. I love how each and every thing can be tweaked without affecting others. Loved it.
