Architecture: Advantages of multi‐module - devrath/RunTracer GitHub Wiki

5 main principles

1️⃣ Separation of concerns

  • We know that there is a dependency on the presentation-layer & data-layer to domain-layer but there is no dependency on domain-layer to other layers, Thus domain-layer is independent.
  • In a single-module architecture, people could easily violate the rule but in multimodule architecture, it's hard to do so.
  • Thus in multi-module architecture, we can enforce strict separation of concerns so that people won't accidentally violate the principles.

2️⃣ Faster gradle builds

  • Gradle has something called incremental building in which it builds just those files that have changed.
  • Example in single module 📦
    • If you make a small change like adding a println() statement on a file in the project that has just one app module, The gradle build is faster when compared to the changes of every file in the app module.
  • Example in a multi-module 📦 📦
    • In this case if you have not made any changes in a module, The gradle will not even go to that module to try to build the module since it understands from the config of the module.
    • It also will be able to build the modules in parallel.
    • In a layered multi-module say you make changes to the data-layer ==> Now the data-module will re-build and also the app-module will be re-built because the data-module is linked to the app-module.
    • If you change the domain layer all the modules need to be re-built since the presentation and data layers are linked to the domain layer.
    • If the changes happen in the presentation layer only the presentation layer will be re-built.
    • In a multi-module gradle needs to change the module that was altered and also the change the module that used the module that got changed
    • Also there is less likely the domain layer would change.

3️⃣ Helps to achieve low coupling & high cohesion

  • LOW-COUPLING
    • Coupling refers to how multiple modules talk to each other.
    • The less coupling the module has, The better it is.
    • In an approach of presentation --> domain <-- data. We can say the presentation layer is coupled to the data layer and the domain layer is not coupled to any layers.
    • There has to be some coupling because the modules need to communicate, but we can minimize this with this type of architecture.
    • Let us assume that there are a lot of modules the data layer is dependent on, In this scenario when changes happen in those layers, this would make the data layer rebuild because it is coupled to those layers.
    • We need to avoid the Waterfall changes because changes in one module cause a lot of other modules to change.
  • High-COHESION
    • This means say a data layer accesses the database or HTTP client only for example.

4️⃣ Easy to enforce guidelines and separation in a team

5️⃣ It supports dynamic modules and instant apps

  • Dynamic feature is just a module that can install dynamically at runtime.
  • Instant apps are similar to dynamic features, built like it lets you try a feature/module without installing it.