- This module represents the conventional
:app
module - It contains the
MainActivity
,Manifest
, and other core app configurations
- Contains the
Convention Plugin
- This module contains submodules like
:network
that handle data fetching viaREST APIs
- Feature-specific business logic modules, such as the
:data
module, will use it to fetch data
- This module holds common code and components shared across different
:feature
modules, such as common UI components
- This is the parent module for individual features
- Features are organized as
submodules
under this module - Typically, feature modules contain four submodules:
:domain
,:data
,:ui
, and:di
- Focuses on
Abstraction
overConcretion
- Acts as a
Mediator
or separator between the:data
and:ui
modules, preventing tight coupling - The
abstraction
should be defined throughinterfaces
orabstract classes
, so noconcrete
implementations exist in this module - It defines
Data Transfer Objects
calledModel
, which represent the structure of data shared between the:data
and:ui
modules - Client modules should not directly use the
Model
for their own purposes; instead, they should extract necessary data from it For example, the:data
module shouldn't use it as anEntity
, and the:ui
module shouldn't use it directly asstate
for UI components This helps reduce coupling between the:domain
module and itsclients
- Contains
business logic
andimplementation
details for what is defined in the corresponding:domain
module - This module includes
Entities
, which represent theJSON
format ofAPI responses
Entities
should beinternal
to this module and not directly used byclient modules
To provide data to client modules, extract the necessary information from theEntity
, build theModel
, and pass it on
- Represents the
dependency injection
container - This module includes
Factory methods
that provide concrete implementations for abstractions defined in the:domain
module but implemented in the:data
module - It maintains a
single source of truth
for object or instance creation, allowing easy changes inimplementation
by modifying theFactory method
without touching client code
- Functions with the
View
suffix represent pieces of UI defined usingComposable
- Classes with the
ViewData
suffix represent thestate
or data used by aView
- These classes should only be used within the
:ui
module The data they receive from theModel
class is converted intoViewData
because theModel
class should not be directly used for other purposes to ensure loose coupling with the:domain
module
- Classes with the
Controller
suffixmanage
thestate
and respond toevents
for a particularView
These can be used for both small and large views - Classes with the
ViewModel
suffix manage the state and respond to events for a Route or destination-levelView
Since these Route-level views are composed of smallerComposable/View
components, theViewModel
serves as aController
and preserves the state across configuration changes
- A
package
namedfactory
defines the concrete classes for the modules - It exposes several
Factory methods
, ensuring that instances are created using these methods instead of direct constructors This helps maintain asingle source of truth
for object creation and allows easy changes to the implementation, ensuring loose coupling
- Represents feature
x
- The
x.components
package defines smaller components, such as UI elements or parts of the UI - The
x.route
package represents screen-level UI, such as screens or routes composed of multiple components