Clean Architecture Dependency Graph (Multi module)

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?

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.