Frogmi Architecture guideline

frogmi_architecture_guideline.md

Project structure guideline

This document describes how modules must be structured.

Clean architecture

Each module use Clean architecture aproach and contains at least 3 sub-packages. domain, data and presentation.

Domain

Execute business logic which is independent of any layer

1. models: Contains models annotated with Room annotations. These classes contains toPresentationModel() which converts models to be usen in presentation layer.

   • Name convention: <Name>Model.kt
   • Dependencies: no dependencies

2. repositories: Behavior descriptions implemented by real repositories in data layer. Only interfaces are allowed here.

   • Name convention: <Name>Repository.kt
   • Dependencies: no dependencies

Data

Dispense the required data for the application to the domain layer by implementing interface exposed by the domain

1. databases: Contains Room database implementation. It should bind all required entities implemented in domain layer. Each database should provide a DAO object which will perfom queries in Database. 1.1 daos: Contains interfaces that works over the database to perform queries

   • Name convention: <Name>Database.kt
   • Dependencies: zero or more DAO interfaces

2. repositories: These are domain implementation of repositories. You should be use it only in usecases.

   • Name convention: <Name><BaseName>Repository.kt (Basename is the domain repository implemented)
   • Dependencies: a Database object

3. usecases: Classes which depends on domain.repositories implementations written in data.repositories.

   • Name convention: <Name>UseCase.kt
   • Dependencies: zero or more domain.repositories objects implemented in data layer

Presentation

Include both domain and data layer and is android specific which executes the UI logic

1. activities: Contains at least one Activity class which will be the entry point of the module (does not apply for Services)

   • Name convention: <Name>Activity.kt
   • Dependencies: zero or one ViewModel object

2. fragments: Contains Fragment classes that can be reached by a destination described in some *_navigation.xml in module. destinations are references to fragment that are used by a Coordinator (does not apply for Services). Fragments can be injected by one ViewModel`

   • Name convention: <Name>Fragment.kt
   • Dependencies:
     • zero or one ViewModel object
     • zero or one Presenter object

3. models: Presentation models used to render in View provided by some Presenter.

   • Name convention: <Name>PresentationModel.kt
   • Dependencies: no dependencies

4. presenters: The "glue" between a ViewState and View. Its classes must implements Presenter interface which provides methods getView() which returns a View to be usen in some Fragment|Activity an update(state: ViewState) which changes View rendering data described in state. Name convention: <Name>Presenter.kt Dependencies: no dependencies

5. viewmodels: These stores and manage UI-related data in a lifecycle conscious way. It allows data to survive configuration changes such as screen rotations. These classes must be implemented only in Fragments or Activitys. ViewModels should be injected only with data.usecases classes

   • Name convention: <Name>ViewModel.kt
   • Dependencies: zero or more UseCase objects

Dependencies

Dependencies of all previous layers are injected by Kodein. All dependencies are described in <module_name>/Dependencies.kt which contains a object with dependency bindings. Typical bindings

1. domain.repositories implementations
2. data.usecases implementations
3. data.database implementations
4. presentation.presenters implementations
5. presentation.viewmodels implementations

Directory structure

• Modules should be named as <name>Feature or <name>Service (lowercaseUppercase classic java notation).
• The proposed directory structure per module is as follows:

<ModuleName>/
 /domain
   /models
   /repositories
 /data
   /databases
   /repositories
   /usecases
 /presentation
   /activities
   /fragments
   /models
   /presenters
   /viewmodels
 Dependencies.kt