Hello ! We're refactoring a large Android applicat...

# android-architecture

[Abdo]

Hello ! We're refactoring a large Android application, Which architecture approach would you recommend for scalability, maintainability, and team productivity? Are there any concerns with either approach for this type of enterprise application ? any Alternative suggestions are welcome.. thanks

[galex]

I like very much this approach https://slack.engineering/stabilize-modularize-modernize-scaling-slacks-mobile-codebases-2/

[Yuvaraj]

I have been using Modularization for long time and found it very efficient, scalable, maintainable and productive. It will save lots of build time and independently you can update and reuse each module/feature without affecting main application.

[Abdo]

@Yuvaraj If we keep data, domain, and ui only as packages, is that enough, or do we really need separate modules to ensure isolation? Because if we have like 20 features, separating each layer would mean managing around +60 Gradle files config.

[galex]

You should do what you feel is good for you and your team

[galex]

I don't separate by layer into modules because it feels unnecessary and my team knows to not call a data source in a VM

[galex]

I separate by library / service/ feature/ app for modules

[galex]

And inside each, you get the necessary layers by package

[Abdo]

Thanks for the insight, @galex !
I totally agree.. package level separation can be sufficient for managing layers effectively, but it really depends on the team’s context

[Ahmed]

AA @Abdo, I recently had the experience of rewriting/restructuring very large ecom apps for scaleability.

On the first rewrite we decided to go with the Approach 1. In the second rewrite, we decided to go with a hybrid approach (Approach 1 + Approach 2).

There is a little learning curve for both approaches and you will have to onboard your team for dos and donts to follow the selected architecture.

The pros and cons are also different for both approaches.

Takeaways are:

If the app is small (a simple/single vertical) OR it does not have any region based variations or feature flags, Approach 1 is fine. Keeps your life simple and easy.

If its a medium to large app OR can have region specific feature flags e.g. region A supports chat feature but region B doesn't. It can be a variation of this ^. You will find yourself more comfortable in Approach 2.

Sometimes, the business logic may change too when you are using Approach 2 e.g region A supports strip payments but region B supports in app currency. In such cases you will find the need to have 2 payments module.

To avoid repeating yourself, you will find the the need to breakdown Approach 2 in more layers. Something like

app/
  core/
    network/
    ui/
    model/
    ...

domain/
  payment/

data/
  payment1/
  payment2/ (if needed)

feature/
  payment-ui-1/
  payment-ui-2/ (if needed)

This will provide you more granular control over your app needs. I have added a variation in every layer, however, this will usually never happen.

This also helps you in more isolated testing and helps with build times as well.

Now it depends your app's need actually.

Please note that will be an overdo/over-engineering if your needs can be met by keeping it simple.

[Abdo]

@Ahmed Great analysis.. I appreciate the pragmatic approach of starting simple and evolving based on actual needs..
What types of models do you put in core/model? Are these: Shared domain entitie or Generic wrappers (like ApiResponse, Error types) ?

I'm asking because I'm trying to balance between:
• Having shared models to avoid duplication
• Keeping feature isolation so teams can work independently
Thanks !

[Ahmed]

Are these: Shared domain entitie or Generic wrappers (like ApiResponse, Error types)

Yes