question about modules about nekome HOT 2 CLOSED

Happy to give some insight into the module structure.
The structure at the moment is a bit of an amalgamation of just trying stuff out, and pulling ideas from other projects I've worked on, luckily it seems to work fairly well.

The general structure I've tried to follow is

• app - Contains as little code as possible, main application class, hilt modules, main activity etc
• features - Contains dedicated features such as "login" or "settings"
• libraries - Contains code that could be pulled into any feature for reusability

with a simple dependency graph being

app -> features
app -> libraries
features -> libraries

One improvement I think that could be made is a deeper set of modules for core components that could be used anywhere such as core or foundation, things like the string resources or retrofit configuration etc would sit there.

Pros and cons of this approach match what you would get with other modular structures, especially when it comes to performance etc.
But pros and cons for this particular structure I've found

Pros:

• Easy to know where to put a new module, removes ambiguity when adding new code
• Project navigation is pretty simple, always know where a component would be
• "Rules" on what can depend on what are usually easy to follow
• Code ownership in bigger teams is easier when you can say "Team X owns the login modules"

Cons:

• Lots of modules, quite easy to keep adding more modules

from nekome.

Thanks for the response. I have decided to also add CLI target for my app so the modules I imagine will be like this

app - you said it will contain as little code as possible, probably it will be a bit different on my app. For example if there would be a screen which is like 20 lines of code, then I will leave it there...
cli - this will be the terminal version of the app

there will be also app-features and cli-features folders with modules, which will contain the logic for their UI. I imagine they will be presentation layers.

and the libraries folder will contain just Kotlin and other libraries that do not have dependency on Android. So it will be possible to reuse them in both CLI and Android variants. They will be like data and domain layer. Looking at the modules Nekome has, all of them depend on Android, for example :libraries:datasource:auth seems to be just Kotlin. Was there a specific reason for having all modules depend on Android?

Found another interesting app having modules. But not yet sure what idea I will copy from them. Most likely 80% of my app will be just like Nekome.

Also watched this video, where a guy mentions apps having hundreds of modules, that would be interesting to see such apps. For mine it probably wont be much since I am alone and hopefuly my will power will last enough...

from nekome.