android10 / Android-CleanArchitecture

This is a sample app that is part of a series of blog posts I have written about how to architect an android application using Uncle Bob's clean architecture approach.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Better understanding of dependency rule?

BokleeBo opened this issue · comments

I am so confused, and every article i came upon is have different dependency rule for MVP/Clean architecture.

At the moment i have 4 Modules in my Android project

App(UI) <--------->Presenter(Java lib) -------->Domain<-------Data

Do i need to pass Data object in Presenter? Which one should i reference i presenter layer Domain or Data?

And where should i write interactor and repositories?

I think Domain layer has to be Java lib too. In my opinion Presenter layer has to use only entities from Domain layer. In Onion architecture (Clean Architecture) the Data layer is just implementation of the Repository (or other "stores") interfaces which provided by Domain layer. All assembly is happened in the App (UI) layer because it is entry point for your application (i mean set specific implementations under interfaces and building dependency graph).

And the answer for your questions:

  1. Interactor has to be in Domain layer (it should operate by abstractions/interfaces), it is business logic;
  2. Repositories have to be in the Domain layer as interfaces (contract), but implementation for specific platform - in the Data layer (in this case we have to avoid implementing repositories interfaces in UI layer to avoid cross dependencies between UI entities and Data entities).

@ultraon Thanks a lot for this. I thought that this kind of questions are not appropriate here.
So, both, Interactor and Repositories must be in Domain Layer, Does interactors are only interfaces? Or a class implemented in Domain Layer?
And where should i implement them? Also in Data Layer?

Sorry, i am a bit confused,where should i put this in correct way.

Implementations of the Interactors should be placed in Domain layer, they are a part of business logic. Preferable to separate Interactors to implementations and interfaces (contract) to be able in simple way make stubs of Interactors for UI/Presenter layer while testing. BTW often we can merge Presenter layer with UI layer. If you feel you can reuse the presenters with other platform then your decision to have Presenter layer is correct (with this approach you sure that Presenter layer doesn't use Android entities e.g. Activity, Fragment, View (Android) on this layer, so you avoid cross-dependencies).

@ultraon
Would you like to explain to me, what are actually Interactors. How should i use them? And for what purpose?

I am really sorry, but i am so confused, with these terms and concepts.

Theoretically, Interactor is a set of similar Use Cases. Use Case is a some behavior (business logic) which resolves some "problem". Use Cases are written according to input product/software requirements (provided by customer). Example: User wants to see the list of products. Use Case (part of it): User should be available to see the list of products. In this case we can name the method "loadProducts()" (it is one Use Case). If you have a set of similar methods (from different Use Cases) you can combine them in one place called Interactor (in this case all methods from all combined Use Cases will be in Interactor).

@ultraon

Thank you Vitaliy.This is what i need it.Terms explained to be understand easily.