Clean Architecture Dependency Graph (Multi module)

Question

When it comes to the Clean Architecture Dependency graph I see two version:

1. The recommended one by Google: presentation -> domain -> data
2. The other: presentation -> domain <- data

What is the design philosophy difference between the two?

Which is more preferable?

What are the main differences?

Answer 1

My personal understanding of both patterns is that it's not an exclusive or if you face their focus.

Clean Architecture has its focus on the Dependency-Graph:

• no entities or domain-internals should import outer layers
• this helps your businesslogic remain indpendent on frameworks or even programming languages

Android Layer-Pattern has a strong focus on DataFlow:

• view must not directly access the data-layer (e.g. in bigger apps, an abstraction should be added through domain-layer)
• this helps to keep your UI independent to external interface-changes

The differences in code-organization may be more obvious. The "data"-module spoken of Android Layer-Pattern may be placed on the outer circle of a CleanArchitecture. Taking the Android Layer-Pattern rules, a ui-module (which remains on same circle) must not access the data-module.

In our team we try to take both as a best standard for our bigger projects.

1. we want to follow a Google-Standard so new devs may be easier onboarded
2. We also want to take the advantages of lose business-logic, which should be easy maintainable on frameworkupdates and
3. the most important, we want to test our domain-parts independent and automatically with a high percentage (>90%) in LOC and branch-coverage

The key to achieve this is using DependencyInversion on the inner layers (domain). Helpful to enforce it in a bigger team is using gradle-modularization and konsit-tests (executed via junit-framework) that are also voting in automated CI-Tests.