Modularization Overview

Modularization Overview

Modularization is the practice of breaking the concept of a monolithic, one-module codebase into loosely coupled, self contained modules.

project-root/ Mifos Mobile
│
├── buildLogic/                # Shared build configuration(Gradle)
│
├── core/                      # Core business logic module
│   ├── common/                # Common code shared across platforms(KMP)
│   ├── model/                 # Model classes and data structures(KMP)
│   ├── data/                  # Data models and repositories(KMP)
│   ├── network/               # Networking and API clients(KMP)
│   ├── domain/                # Domain-specific logic(KMP)
│   ├── ui/                    # UI components and screens(CMP)
│   ├── designsystem/          # App-wide design system(CMP)
│   └── datastore/             # Local data storage(KMP)
│
├── feature/                   # CMP Feature Specific module
│   ├── about/                 # CMP about specific module
│   ├── accounts/              # CMP account specific module
│   ├── auth/                  # CMP auth specific module
│   ├── beneficiary/           # CMP beneficary specific logic
│   ├── client-charge/         # CMP faq specific logic
│   ├── guarantor/             # CMP guarantor specific logic
│   ├── help/                  # CMP help specific logic
│   ├── home/                  # CMP home specific logic
│   ├── loan/                  # CMP loan specific logic
│   ├── location/              # CMP location specific logic
│   ├── notifiaction/          # CMP notification specific logic
│   ├── qr/                    # CMP qr specific logic
│   ├── recent-transaction/    # CMP recent-transaction specific logic
│   ├── savings/               # CMP payments specific logic
│   ├── settings/              # CMP profile specific logic
│   ├── third-party-transfer/  # CMP qr specific logic
│   ├── transfer-process/      # CMP transfer-process specific logic
│   ├── update-password/       # CMP update-password specific logic
│   └── user-profile/          # CMP user-profiel specific logic
│
├── androidApp/                # Android Application module
├── iosApp/                    # iOS Application module
│
└── shared/                    # Shared Kotlin Multiplatform code

flowchart TB
    subgraph Mifos[Mifos Mobile Project]
        direction TB
        
        subgraph Core[Core Module]
            direction LR
            kmp[KMP Modules<br/>common, model, data<br/>network, domain, datastore]
            cmp[CMP Modules<br/>ui, designsystem]
        end
        
        subgraph Features[Feature Modules]
            direction LR
            auth_group[Auth Features<br/>auth, update-password]
            account_group[Account Features<br/>accounts, user-profile<br/>settings]
            transaction_group[Transaction Features<br/>loan, savings<br/>recent-transaction<br/>third-party-transfer<br/>transfer-process]
            other_group[Other Features<br/>about, beneficiary<br/>client-charge, guarantor<br/>help, home, location<br/>notification, qr]
        end
        
        Apps[Platform Apps<br/>androidApp, iosApp]
        Build[Build Logic]
        Shared[Shared KMP]
    end
    
    %% Connections
    Core --> Apps
    Features --> Apps
    Shared --> Apps
    Build --> Apps
    
    %% Styles
    classDef default fill:#ffffff,stroke:#333,stroke-width:2px,color:#333
    classDef mifosGroup fill:#f8f9fa,stroke:#495057,stroke-width:3px,color:#212529
    
    classDef coreGroup fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#0d47a1
    classDef featureGroup fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px,color:#4a148c
    
    classDef kmpModule fill:#bbdefb,stroke:#1976d2,stroke-width:2px,color:#0d47a1
    classDef cmpModule fill:#90caf9,stroke:#1976d2,stroke-width:2px,color:#0d47a1
    
    classDef authModule fill:#e1bee7,stroke:#7b1fa2,stroke-width:2px,color:#4a148c
    classDef accountModule fill:#ce93d8,stroke:#7b1fa2,stroke-width:2px,color:#4a148c
    classDef transactionModule fill:#ba68c8,stroke:#7b1fa2,stroke-width:2px,color:#4a148c
    classDef otherModule fill:#ab47bc,stroke:#7b1fa2,stroke-width:2px,color:#ffffff
    
    classDef appModule fill:#ffcdd2,stroke:#c62828,stroke-width:2px,color:#b71c1c
    classDef buildModule fill:#ffe0b2,stroke:#ef6c00,stroke-width:2px,color:#e65100
    classDef sharedModule fill:#c8e6c9,stroke:#388e3c,stroke-width:2px,color:#1b5e20
    
    %% Apply styles
    class Mifos mifosGroup
    class Core coreGroup
    class Features featureGroup
    
    class kmp kmpModule
    class cmp cmpModule
    
    class auth_group authModule
    class account_group accountModule
    class transaction_group transactionModule
    class other_group otherModule
    
    class Apps appModule
    class Build buildModule
    class Shared sharedModule

Loading

Benefits of modularization

This offers many benefits, including:

Scalability - In a tightly coupled codebase, a single change can trigger a cascade of alterations. A properly modularized project will embrace the separation of concerns principle. This in turn empowers the contributors with more autonomy while also enforcing architectural patterns.

Enabling work in parallel - Modularization helps decrease version control conflicts and enables more efficient work in parallel for developers in larger teams.

Ownership - A module can have a dedicated owner who is responsible for maintaining the code and tests, fixing bugs, and reviewing changes.

Encapsulation - Isolated code is easier to read, understand, test and maintain.

Reduced build time - Leveraging Gradle’s parallel and incremental build can reduce build times.

Dynamic delivery - Modularization is a requirement for Play Feature Delivery which allows certain features of your app to be delivered conditionally or downloaded on demand.

Reusability - Proper modularization enables opportunities for code sharing and building multiple apps, across different platforms, from the same foundation.

Modularization pitfalls

However, modularization is a pattern that can be misused, and there are some gotchas to be aware of when modularizing an app:

Too many modules - each module has an overhead that comes in the form of increased complexity of the build configuration. This can cause Gradle sync times to increase, and incurs an ongoing maintenance cost. In addition, adding more modules increases the complexity of the project’s Gradle setup, when compared to a single monolithic module. This can be mitigated by making use of convention plugins, to extract reusable and composable build configuration into type-safe Kotlin code. In our project, these convention plugins can be found in the build-logic folder.

Not enough modules - conversely if your modules are few, large and tightly coupled, you end up with yet another monolith. This means you lose some benefits of modularization. If your module is bloated and has no single, well defined purpose, you should consider splitting it.

Too complex - there is no silver bullet here. In fact it doesn’t always make sense to modularize your project. A dominating factor is the size and relative complexity of the codebase. If your project is not expected to grow beyond a certain threshold, the scalability and build time gains won’t apply.

Modularization strategy

It’s important to note that there is no single modularization strategy that fits all projects. However, there are general guidelines that can be followed to ensure you maximize its benefits and minimize its downsides.

A barebone module is simply a directory with a Gradle build script inside. Usually though, a module will consist of one or more source sets and possibly a collection of resources or assets. Modules can be built and tested independently. Due to Gradle's flexibility there are few constraints as to how you can organize your project. In general, you should strive for low coupling and high cohesion.

• Low coupling - Modules should be as independent as possible from one another, so that changes to one module have zero or minimal impact on other modules. They should not possess knowledge of the inner workings of other modules.

• High cohesion - A module should comprise a collection of code that acts as a system. It should have clearly defined responsibilities and stay within boundaries of certain domain knowledge. For example, the core:network module in our project is responsible for making network requests, handling responses from a remote data source, and supplying data to other modules.

Modularization in Mifos Mobile

Our modularization approach was defined taking into account the “Mifos Mobile” project roadmap, upcoming work and new features. Additionally, our aim this time around was to find the right balance between overmodularizing a relatively small app and using this opportunity to showcase a modularization pattern fit for a much larger codebase, closer to real world apps in production environments.

This approach was discussed with the Android community, and evolved taking their feedback into account. With modularization however, there isn’t one right answer that makes all others wrong. Ultimately, there are many ways and approaches to modularizing an app and rarely does one approach fit all purposes, codebases and team preferences. This is why planning beforehand and taking into account all goals, problems you’re trying to solve, future work and predicting potential stepping stones are all crucial steps for defining the best fit structure under your own, unique circumstances. Developers can benefit from a brainstorming session to draw out a graph of modules and dependencies to visualize and plan this better.

Our approach is such an example - we don’t expect it to be an unchangeable structure applicable to all cases, and in fact, it could evolve and change in the future. It’s a general guideline we found to be the best fit for our project and offer it as one example you can further modify, expand and build on top of. One way of doing this would be to increase the granularity of the codebase even more. Granularity is the extent to which your codebase is composed of modules. If your data layer is small, it’s fine to keep it in a single module. But once the number of repositories and data sources starts to grow, it might be worth considering splitting them into separate modules.

We are also always open to your constructive feedback - learning from the community and exchanging ideas is one of the key elements to improving our guidance.

Note

This project followed Google recommend architecture and modularization pattern. followed the Now in Android App modularization approach and mostly content of this page are copied from it..