All your videos have been super helpful! I'm starting to understand why we do certain things instead of just following what Google recommends in the guidelines. The Android learning curve is steep, but videos like these give me a deeper understanding.
Where goes the single responsibility principle when all the layers implement the interfaces from the domain layer? What about seperation of concerns? Why the domain layer should know what the data layer repository response should look like?
I'm new to this. Can someone explain me where should android specific things go like workers, notification, Bluetooth implementations go? Dependency injection?
This is secret knowledge that nobody shares, like literally nobody wants to touch this topic probably because it's hard to fit such elements into this architecture.
On another module which is an Android library, and the module which holds the ViewModel refers to it. A use case in the domain layer may reference it too, but it'd then also have to be an Android library which you may not want, so probably straight from the ViewModel would be more popular. Then in turn, that WorkManager or whatever may have to look into whatever module gives them access to the database, network or whatever.
These things are bound to android platform, in my case I put all in the presentation(UI) layer. Someday if you need to change your project to Web(example) u will not move the presentation layer.
While, from your demonstration, I see the difference between those two architectures, does it have any practical meaning when following one over the other? If the only real difference is the placement of the data source implementations, I can't think of what impact can this have... (maybe the build times when changing these implementations?)
Here's my principle. An interface that has only one implementation is boilerplate. And if you like buzz words, here's one for you; Poltergeist: "The poltergeist anti-pattern occurs when we have a bunch of infrastructure code that serves the design but is otherwise useless." So, if it wasn't clear, I'm not going to add a bunch of interfaces in between my Repos, just to change the direction of an arrow on a PowerPoint slide. That's religion, not science.
Hello Erik. Nobody forces you to add anything, it's your code. And your decision at the end of the day. The success of your decision will be measured in the future, both by your future self and your colleagues working on your code base. Have a good day.
Hello Erik. Nobody forces you to add anything, it's your code. And your decision at the end of the day. The success of your decision will be measured in the future, both by your future self and your colleagues working on your code base. Have a good day.
All your videos have been super helpful! I'm starting to understand why we do certain things instead of just following what Google recommends in the guidelines. The Android learning curve is steep, but videos like these give me a deeper understanding.
I am very happy to read your comment, thanks a lot!
Best explanation of Clean Architecture I've heard in 9y of software development.
Thank you so much for such a kind comment!
Great video, appreciate your attention to detail here 👏
Much appreciated! Thanks for watching!
Thanks for making this video!
Well explained. Thank you!
Thank you for your comment!
Where goes the single responsibility principle when all the layers implement the interfaces from the domain layer? What about seperation of concerns? Why the domain layer should know what the data layer repository response should look like?
I'm new to this. Can someone explain me where should android specific things go like workers, notification, Bluetooth implementations go? Dependency injection?
This is secret knowledge that nobody shares, like literally nobody wants to touch this topic probably because it's hard to fit such elements into this architecture.
On another module which is an Android library, and the module which holds the ViewModel refers to it. A use case in the domain layer may reference it too, but it'd then also have to be an Android library which you may not want, so probably straight from the ViewModel would be more popular. Then in turn, that WorkManager or whatever may have to look into whatever module gives them access to the database, network or whatever.
just do it in the UI
These things are bound to android platform, in my case I put all in the presentation(UI) layer. Someday if you need to change your project to Web(example) u will not move the presentation layer.
While, from your demonstration, I see the difference between those two architectures, does it have any practical meaning when following one over the other? If the only real difference is the placement of the data source implementations, I can't think of what impact can this have... (maybe the build times when changing these implementations?)
There are a lot of differences. And I will try to showcase this in a real example in a follow up video.
great and well-explained
Thank you :)
isn't repoimpl should be on a data layer and repo interface should be on the domain?
Exactly.
Here's my principle. An interface that has only one implementation is boilerplate.
And if you like buzz words, here's one for you; Poltergeist:
"The poltergeist anti-pattern occurs when we have a bunch of infrastructure code that serves the design but is otherwise useless."
So, if it wasn't clear, I'm not going to add a bunch of interfaces in between my Repos, just to change the direction of an arrow on a PowerPoint slide. That's religion, not science.
Hello Erik. Nobody forces you to add anything, it's your code. And your decision at the end of the day.
The success of your decision will be measured in the future, both by your future self and your colleagues working on your code base.
Have a good day.
Hello Erik. Nobody forces you to add anything, it's your code. And your decision at the end of the day.
The success of your decision will be measured in the future, both by your future self and your colleagues working on your code base.
Have a good day.
brilliant
Thanks a lot 🙏