philipplackner / cryptocurrencyappyt Goto Github PK

Line 17 @GetCoinsUseCase

How and where would you implement paging to this project using this approach?

Hi there. I really like your videos. I've been practising Clean Architecture for some years, but as you know the implementation is open to interpretation, so I'm always interested in other people's perspective. This issue is just a comment/request for opinion (and not a critic!).

Some points I think could be more aligned with Clean Architecture:

• Data DTOs: I'd try keep the DTOs pure and anemic, without those toDomainVersion convenience functions. The DTOs change with the API while the domain objects change with domain changes. This mapping could be better contained in a different file to decouple both models, although it is Ok if you are 100% sure there will be no changes.

• Data repository: I would have kept it synchronous (no suspend, no LiveData, no nothing!). Right now you are coupling your interface to a particular async library (Coroutines). But in Clean Architecture you usually want to postpone these decissions for later. You might want to use RxJava or whatever other library. This choice can be made later in a more external layer (domain or better yet, application). This also makes testing of the data package easier, and makes porting it to a different technology also a lot easier.

• Domain model: Coin and CoinDetail are two different classes, but in real life CoinDetail is also a Coin, just with extra info, and you are not expressing this relationship in the code.
  I'd have created just a single Coin class with an optional Details member inside, that could be retrieved as needed.
  I like that you have kept them immutable and pure Kotlin. If you were implementing persistence, don't add here all those Room annotations. Create instead a separate persistence model in the data package.

• Domain "use cases" (actually Domain Services): These two existing use cases could be fused into one single class, a CoinService, with two methods. Also notice that there is no significant domain logic whatsoever in these use cases, so for this particular sample app you could get rid of this layer and go straight for an application layer (or even the ViewModels) to wrap your repository calls into async constructs (although in your case they were already async) and handle exceptions. The domain layer is mostly meant for "business transactions", pure domain methods that don't belong in a particular domain class. Calling the network or retrieving from persistence is not really something specific of the domain (the coins).

• DI: Use it only on your external layers. No @Inject annotations polluting your inner classes (eg: CoinRepositoryImpl). Believe it or not, you can also decide to change your DI library some day, and we don't want the entire code base to be tied to it.

Close empty repos