Thanks for the content! I have a theoric doubt: in the design using the Adapter pattern, the ModuleB is pertain to Interface Adapter Layer or Infrastructure Layer? I mean, did it become like an external lib for my application?
Dependency inversion can be applied everywhere. If you refer to clean architecture then dependency inversion is applied on all layers to ensure dependencies only inwards.
So everyone keeps saying about how great it is to use an abstractions for such things as DB, but does it really bring benefits? Do people often change the DB context to something else? Besides something like Logger, which one might change from text to sentry to idk email, everything else is just not happening. The real benefit is in testing/mocking things.
@AlexZavalny In past 20 years I have seen so many technologies and libraries come and go which, depending on the size of your code base and the degree of coupling, can be really hard to replace. And as I tried to explain in the video this may not only happen due to obsolescence but also because of requirement changes which are hard to predict. So yes, based on my experience I see real and even big benefits of putting an "anti corruption layer" between third party libraries/technologies and the actual application logic.
@@AboutCleanCode Now when you say, I understand that you are right. I remember how I hardcoded using some fraud detection library for our ecommerce system and then company asked to switch to something else, which required search all references and rewrite.
@AlexZavalny maybe you are right - still I used it intentionally because I see many developers using it in their app logic without thinking about the impact when having to switch to some completely different storage technology in some years which they cannot even imagine today 😉
Do people really change the db context? Have seen people ask that question repeatedly. Yes, it is replaced during unit tests. You shouldn't use dB context in unit tests or make network calls.
Your channel is way underrated. Awesome content and easy to follow along!
Very amazing content. The DI is not simply DI. You add a context, you explain both for a junior level and an advanced level. Thank you
Great introduction to the idea, this video is criminally underrated.
Brilliant explanation, easy to wrap your head around. Thank you!
This channel contains some really practical suggestions for how to do Clean Code. Many Thanks! Looking forward to more content. Subcribed!
This was really beautifully explained! I hope your channel will grow more.. Keep it going :)
Thanks for the content! I have a theoric doubt: in the design using the Adapter pattern, the ModuleB is pertain to Interface Adapter Layer or Infrastructure Layer? I mean, did it become like an external lib for my application?
Dependency inversion can be applied everywhere. If you refer to clean architecture then dependency inversion is applied on all layers to ensure dependencies only inwards.
Well explained. Thank you.
Finally some basic that I could follow. Using adapter for reusablity of data access in clean architecture. I got some insight, thank you.
So everyone keeps saying about how great it is to use an abstractions for such things as DB, but does it really bring benefits? Do people often change the DB context to something else? Besides something like Logger, which one might change from text to sentry to idk email, everything else is just not happening. The real benefit is in testing/mocking things.
@AlexZavalny In past 20 years I have seen so many technologies and libraries come and go which, depending on the size of your code base and the degree of coupling, can be really hard to replace. And as I tried to explain in the video this may not only happen due to obsolescence but also because of requirement changes which are hard to predict. So yes, based on my experience I see real and even big benefits of putting an "anti corruption layer" between third party libraries/technologies and the actual application logic.
@@AboutCleanCode Now when you say, I understand that you are right. I remember how I hardcoded using some fraud detection library for our ecommerce system and then company asked to switch to something else, which required search all references and rewrite.
I still thing that DB context is not the most obvious example @@AboutCleanCode
@AlexZavalny maybe you are right - still I used it intentionally because I see many developers using it in their app logic without thinking about the impact when having to switch to some completely different storage technology in some years which they cannot even imagine today 😉
Do people really change the db context? Have seen people ask that question repeatedly.
Yes, it is replaced during unit tests. You shouldn't use dB context in unit tests or make network calls.