Within Clean Architecture, the Domain layer defines Use Cases which define operations which can be performed in our Android project. In this lesson, we’ll be creating some base classes which these Use Cases will inherit from to save us writing boilerplate code repeatedly in our Use Cases implementations.
Amazing tutorial but has a learning curve, I am starting to understand the content after I am seeing a lot of course lessons after this.
I would suggest to put more graphic architectural slides so that we can understand how the interactor/ use cases are linked to other data layers (repository and view considering the not flat but onion clean code structure). BECAUSE I start to understand why you pass all these T, only when I look at the repository, so I am wondering when we architect ourself should we start from the Repository defining the clear cases, or so abstract as you do?
For instance in CompletableUseCases
you pass (in Params) and not saying "that completable does not return any data" fair enough, so why you are still passing
in Params as producer? and why you are passing Nothing after?
Even better if you could spend two words about why is needed in Params as covariant ( old ? super Java) way. Also I suggest to mention when you are using SOLID principles. Great tutorial, maybe the best I ever followed, sorry to try to be so picky but I would be glad to fully understand everything. I am learning a lot by you. This will influence all my way to write code.
Domain layer should not know anything about the other layers but as it turns out in this implementation, domain layer knows almost everything about rx java and its api, like subscribing, completable, observable, disposable etc, I don't think this is clean architecture since rxjava is hard coded into the domain layer. However this does separate concerns but it is not clean by any stretch of imagination.
Correct, the Domain layer shouldn't know anything about other layers. However, the thing is we are adapting this to an Android environment and if you wish to use RxJava then this is difficult to completely abstract out of our layer (and if we were to do so, the codebase would be more complicated than it needs to be). In the videos you'll notice that we do abstract out the Execution Thread and the Scheduler so that this layer has no reference to the Android framework, which was our intention - personally this is enough but really, it comes down to a matter of opinion as to how abstract you want your codebase to be :)
If we wanted to go further on this, we could provide an abstract subscriber class which is used by the presentation layer, so that the domain layer could use this. Therefore if we were to remove RxJava at any point the process of doing so would be a tad easier.