After executing ADR#1: Modularization we ended up with confusing modules structure and a lot of :temp
, :app-base
and other "workaround" modules required to build the app successfully.
We plan to address that by:
- Organize our modules better.
- Leverage submodules (e.g.
:core:actions
).
After the migration to modularized migration we ended up with a big ball of mud scattered around multiple modules w/o logical structure.
- complexity++
- coupling.
- hard for developers to add the right dependencies to new modules.
- a lot of unnecessary dependencies.
- hard to navigate the project.
- slower build times.
- it's bad!
Create a logical structure of modules and submodules having in mind that one-day we may want to migrate this project to KMP (Kotlin Multiplatform).
Goal:
- reduce the number of root modules.
- make navigation easier.
- remove coupling and unncessary dependencies.
- reduce complexity.
:core:data-domain
: Ivy's data model [Transaction
,Account
,Category
, ...]:core:data-ui
: transformation ofdata-domain
so it's optmized for UI and Jetpack Compose:core:functions
: pure functions:core:actions
: re-usable use-cases for domain logic:core:ui
: re-usable UI components providing extension functions fordata-ui
:core:persistence
: handling local persistence RoomDB
No code module, containing only resources. Why?
- It'll make it easy to access all Ivy icons and strings when you develop.
- It'll be easy for contributors to manage
strings.xml
and translations. - R8 will optimize so there's no big cost.
See ADR#3: Jetpack Navigation. TL;DR;
- define all possible nav destinations in
:navigation
. - wire nav destionations with @Composable UI in
:app
:common
: light weight module used to provide common deps for any module.:design-system
: Ivy Design system:sync
: logic for syncing your data to Ivy Cloud (deprecated) and soon Google Drive
:state
becauseFlow
will handle it under the hood.- all
temp-*
modules. :ui-common
->:design-system
.:ui-components-old
->:core:ui
.:app-base
- decouple and remove.:data-model
->:core:data-domain
.
- clear module structure.
- de-coupling.
- easier navigation between modules.
- faster builds.
- reduces overall complexity.