I’m curious on how do you structure your projects ...
# android-architecture
e
I’m curious on how do you structure your projects for those who use Clean Architecture and modularisation? What pros and cons have you noticed with that type of code/folder structure?
n
Old way: Presentation, Domain, Data layers New way with feature split: Feature\Core etc. directories with relevant modules inside. Examples projects with feature spit architecture: https://github.com/android/nowinandroid https://github.com/fvilarino/Weather-Sample Outside of setting boundaries the main purpose of modularization is usually to improve build performance or sometimes to share code parts between projects. But it comes with overhead of supporting proper configuration of those modules, making plugins for gradle etc. This is basically cons\pros. My opinion: there is no definitive rule, but if you have small to mid project and a small dev team you might be totally fine doing everything inside app module, but keeping it’s package structure ready to split into separate modules when you need it.
👍 2
e
Thank you Nick for your response. My question in this matter was for ways that you use to modularise you project, for example having the modules divided by feature just like you mentioned I know that there is no rule thats why I asked how are you doing it. For example here is a way that I’ve used and I like — app -- core — core-ui -- feature1 — feature2 then each feature would have the domain data and presentation layers while the core module would consist of classes that you would use across the app without the ui stuff and core-ui would contain the common ui stuff that you would need across the app. This way you wouldn’t put dependencies for UI in core module.
n
In my experience it was hard to split app into features so that each feature has a Domain and Data layer inside it. Usually it’s just a UI related staff, ViewModel, navigation. And Domain and Data code are actually a part of the Core modules.
2
❤️ 2