Android multi-module architecture: domain depends on data or vice versa

Question

Some Android multi-module architecture examples show that domain layer depends on data. Others are vice versa.

Android Developers site says:

The domain layer is an optional layer that sits between the UI layer and the data layer.

Also it shows picture where domain depends on data:

Meanwhile another article on proandroiddev.com says:

1.

Domain Layer is the most INNER part of the onion (no dependencies with other layers) and it contains Entities, Use cases & Repository Interfaces. Use cases combine data from 1 or multiple Repository Interfaces.

One of the most common mistakes is to have your app driven by your data layer/specific data system.

Domain Layer does NOT depend on Data Layer.

And appropriate image shown:

So could you please describe which approach is better for Android multi-module and why?

Answer 1

If taken into consideration both of the Docs are correct with the proper context of what you want to achieve.

You want to implement a solution just & just for Android, the Android developer's doc is more suitable for it. You want to create a project which can target for Multiple platform (Android, iOS, desktop), the ProAndroidDev's architecture is more suitable.

Also, while reading their doc, I want you to keep their end goal and context in mind.

In Android developer's doc, the Data Layer consists of Entity & Repository classes. These classes are required in Usecase classes & hence there is dependency of Domain layer on data layer. In this architecture, the assumption is that you are building the App only for Android, so there is no need of creating an abstraction for Repository classes, since it would create more complexity.

In ProAndroid dev's doc, the assumption is that maybe you are building the App for Android for now and later you may introduce other platforms or you are targeting for multiple platforms now only. In this case, the Repository class abstraction become a lot more important, since by adding it in early stage, you may reduce your future bugs/refactor. In this doc, to achieve above purpose, instead of Data layer, the domain layer now contains the Usecase, Entity & Repository interface classes & Data Layer contains the Repository Impl classes. As a result, the domain layer does not need any dependency & hence it should not have any dependency on other layer.

I think in ProAndroid dev's blog, if they had referred the layer containing Repositories as Repository Layer instead of Data Layer, then this confusion could have been avoided. In Android's blog, they refer it to Data layer since it contains the actual data/POJO classes & Repository classes (Classes responsible for managing this data).

Answer 2

I will try to respond independently of Android because I am not an expert at it at all. From a pure design overview:

Some points to note:

• There is no fixed number of layers in any architecture.
• DataLayer are not only about data that come from database, it can be any data that come from outside the application (API...). You may call that a Dependency to simplify things, like Robert Martin did in Clean Architecture.
• There is always a dependency, layers are just an abstraction and a way to recognize things. We try not to depend a lot on data but there is always a dependency. But let's make some things easier.

What we try to do in a design is create scopes (layers, classification) to separate concerns and add abstraction. There are a lot of architecture that they have try to put this in place with different manner, but the goal was the same:

• Good classification / abstraction
• Little coupling on Dependency (Frameworks and external system: database, Api...)
• Make system change easier and keep change impact limited

I agreed with Ashok the two Docs are correct at a certain level. It depend on which architecture you will follow: Domain layer is always about the kernel of your system. It means what features and what problem the software is resolving. You implement in this layer independently from external system, framework, application layer (endpoint, how to expose your program features ....) That is why we call it domain layer. Some development pattern or strategy like Domain Driven Design may be suitable to develop this kind of layer and give you more techniques and options to succeed to implement it correctly or more cleaner. I suggest to take a look on it (try to find a good resources or just buy the book of Eric, many persons on internet explain this design incorrectly).

So this layer will have their classes (domain entity, may be services...) What is called in the 2 Docs DataLayer (I am calling it Dependencies = External System Dependency + Frameworks Dependencies) Your Domain Layer should only depend on interfaces from this layers. The Domain layer should not give interest on the implementation of Dependencies.

Presentation when it start to consume Domain Layer (may be by direct call, or via API, it depend on the application) it should not make their Views (UI) depend on the structure of classes/objects exposed by the Domain. The Presentation layer should create its own classes/objects and convert the data exposed by the Domain. This avoid that a change in the domain break your Presentation Layer.

NOTE: In a design where the Frontend is separated from the Backend, another layer called Application layer may contains endpoints that expose Domain features to the Presentation Layer.

Sorry this kind of question is very difficult to answer briefly. Don't hesitate to get in touch with me for more clarification.