Android Modularisation using Clean Architecture and other Components

Damilola Omoyiwola
4 min readNov 22, 2020

--

For quite some time now, I have been in the quest of attempting the trends in Android Development. It was actually difficult to find an article that has most of the components I wanted. However, after so much study, I was able to come up with a concrete solution that I would like to share.

Here, I will discuss how I migrated a single module project to a multi-module using Clean Architecture (CA) alongside some other components and MVVM architectural design pattern.

Scope

This article:

  • will be in parts and each part will showcase its intended purpose
  • will focus on the technical aspects to avoid long read
  • will provide references to understand the components used and the non-technical aspects of the codes

In case you need an overview of what CA by Uncle Bob is, you could check this out else, you should proceed to the next section. Perhaps, you just want to zoom straight to the code setup, here you have it 😎

Project Overview

The project can be found here. The master branch contains the single module while the develop branch contains the refactored code.

The app uses a single activity pattern which comprises:

  1. List of daily fixtures
  2. List of football competitions
  3. List of teams, fixtures, tables, and players per competition

So, how was this structured?

Based on the UI design, I decided to split these views into two features namely: competitions and competition details.

Project Structure

Following the CA with its abstraction, each of the layers was placed in a separate module. The image below shows how I structured the modules.

Football Fixtures Modules

Now, let me explain the modules above.

Presentation Layer:

  • App Module houses the HomeActivity since a single activity is used. Nothing else in this module.
  • Features Directory is a directory for all the different feature modules (this is different from the Dynamic Feature Module). The competitions module shows the fragments in the bottom navigation which displays a list of daily fixtures and competitions while the competitionDetails module shows a viewpager with its respective fragments that display the fixtures, tables, standings, and teams per competition.
  • Presentation Module is responsible for exposing data wrapped in entities that users observe via a LiveData perhaps in the ViewModel class.
  • Navigation Module helps with navigating through the app using the Jetpack’s Navigation Component. This module is accessible to all the feature modules. Instead of having different navigation graphs in all the modules, I decided to pull them together in this module for easy access amongst modules.

Domain Layer: This has the Domain Module which contains the usecase responsible for enclosing a particular task, repository interfaces, and entities I tag as DomainEntities . From the image above, we could see that other layers depend on the domain layer for successful transactions 😄. I mean it serves as an errand boy or an intermediary 😏

Data Layer: This includes the Data Module which is responsible for providing a single source of truth even when sometimes the origin may not be known (like I don’t want to know whether the data is coming from an API or a DB 🤷‍♀). It implements the repository interface defined in the domain layer.

Secondary Modules: I call the Core and Common modules secondary because I chose to and they are not mandatory. The Core module is where all common setups like dependency injection, common classes like Database module, etc. are done.

In the Common module classes like base views, resources, utilities shared amongst modules are placed here. You could name it anything you want like some do call it Shared.

Here is how it looks like in the AS IDE:

Project Structure

In addition, the image below shows how the different modules depend on one another.

We could see that none depends on the app module and the common module depends on none.

To understand how the codebase is being set up, check out Easy Setup of Dagger2 and other Components in a Multi-module App using Clean Architecture.

Conclusion

One of the reasons I like the CA with multi-module is that it makes code reuse easy in case the presentation layer changes due to users’ preferences on the looks and feel of the app. Also, it eases off the stress of code refactoring i.e. you could track your progress according to the modules.

Thanks for reading through!

If you want to tell me something 😄, kindly comment and if you ❤️ this article, please feel free to 👏 and share.

--

--