Thank you for the video. Your explanation was quite clear despite the content being quite complex. I confess I must see the video 2 or 3x to absorb the content. Helped a lot!
Hey people! In my next videos I will make a challenge with 3 of my subscribers. The winner will get 200 US$. If you want to participate, add me on LinkedIn. First come, first served.
Really good video. You almost made it until you got to the data layer. The details and conformance to the contracts defined in the domain layer should NOT live in the center of the onion. that is a violation of CLEAN which dictates that dependencies flow in and external concrete implementations that depend on external resources for instance live on the outside of the onion, on the edges.
@@EricWalker-i4u the details of the implementatation ate not in the center of the architecture but in the outer most layer, the data layer, or did I miss something?
Good point, very often Use Cases does nothing but call the repositories, if there is no "use case" for a use case then there is no problem having a repository in the viewModel, as long as the repository is an interface
Stop calling Android architecture principles from google documentation "Clean architecture". Android documentation make it clear that your data layer is the most important/source of truth etc. In real clean architecture you make Repository an interface located in domain layer. That way you follow Inversion of Control principle to make domain the most important layer in your application. It is very frustrating and brings a lot of confusion. By the way it does not mean that architecture in your video aka Google recommended architecture is wrong, it is just not Clean Architecture from Uncle Bob book.
@@Abhishekdubey-mn8up They are wrong you shouldn't do that. Imagine a scenario where you change the behavior of one usecase then you might have to alter the calling usecase as well. Follow the clean architecture and solid principles not the MAD skill
I think both points are valid, in some cases it might be useful and desired to change the behaviour of all use cases that use some use case, otherwise we would have to duplicate the code. But you do have a point that we should be aware of this dependency and when it might not be desired.
I am glad you liked. The ideas came from this book: Clean Architecture: A Craftsman's Guide to Software Structure and Design, really recommend. I will try to create some videos about unit testing, I explain about it in the course(description) but I do not have some videos about it yet.
Thank you for the video. Your explanation was quite clear despite the content being quite complex. I confess I must see the video 2 or 3x to absorb the content. Helped a lot!
Thanks for the great explanation
Also autogenerated subtitles are perfect in your videos, thats really great too
Glad to read this!
Hey Renaro, great video! Thanks for explaining it so simple!
Happy that you liked it.
Wow thank you! Such compact yet very clear explanation
Where should we put service, broadcast receiver, work manager etc
They are the implementation details of "a repository" so they should go in the data/repository layer
wow, fantastic explanation!
Glad to read!
Hey people! In my next videos I will make a challenge with 3 of my subscribers. The winner will get 200 US$. If you want to participate, add me on LinkedIn. First come, first served.
Really good video. You almost made it until you got to the data layer. The details and conformance to the contracts defined in the domain layer should NOT live in the center of the onion. that is a violation of CLEAN which dictates that dependencies flow in and external concrete implementations that depend on external resources for instance live on the outside of the onion, on the edges.
@@EricWalker-i4u the details of the implementatation ate not in the center of the architecture but in the outer most layer, the data layer, or did I miss something?
no deberia haber ninguna instancia de un repository en el viewmodel, ya que es el caso de uso quien se comunica con el repository
Good point, very often Use Cases does nothing but call the repositories, if there is no "use case" for a use case then there is no problem having a repository in the viewModel, as long as the repository is an interface
Nice Video you just gained a sub
Glad you liked!
Hai, sir. Could you give a simple example using Single Event for live data with Repository?
In the description I added a sample project, what are you looking for exactly?
Stop calling Android architecture principles from google documentation "Clean architecture". Android documentation make it clear that your data layer is the most important/source of truth etc.
In real clean architecture you make Repository an interface located in domain layer. That way you follow Inversion of Control principle to make domain the most important layer in your application. It is very frustrating and brings a lot of confusion. By the way it does not mean that architecture in your video aka Google recommended architecture is wrong, it is just not Clean Architecture from Uncle Bob book.
I agree. This is not Uncle Bob's CA. This is just a modified MVVM.
awsome！cool！
THANK YOU
Happy that you liked it
Great video nicely explained ❤️
Nice video!
thanks! :)
Ideally usecases shouldn't depend on each other.
I think you are right, then changing one use case might affect others...
Use cases can depend on each other.
As per Google recommendation in MAD skills architecture video with domain layer.
@@Abhishekdubey-mn8up They are wrong you shouldn't do that. Imagine a scenario where you change the behavior of one usecase then you might have to alter the calling usecase as well. Follow the clean architecture and solid principles not the MAD skill
I think both points are valid, in some cases it might be useful and desired to change the behaviour of all use cases that use some use case, otherwise we would have to duplicate the code. But you do have a point that we should be aware of this dependency and when it might not be desired.
Awsome
Hey bro, nice video, could you add references of your info? Also could you create videos of unit testing and clean architecture, please? Thanks a lot!
I am glad you liked. The ideas came from this book: Clean Architecture: A Craftsman's Guide to Software Structure and Design, really recommend.
I will try to create some videos about unit testing, I explain about it in the course(description) but I do not have some videos about it yet.
Great work, I’m going to check that book and some testing in your channel will be awesome.
Thanks for take time to answer!
Understood
awesome