androidarchitectureclean-architecturemulti-module

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?


Solution

  • 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:

    Android Layer-Pattern has a strong focus on DataFlow:

    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.