Skip to content

PLAN | Domain Layer & Use Case Implementation #27

Closed
4 of 4 issues completed
Closed

Description

@alexistercero-rho-dev

Development plan for Domain Layer

This feature is part of the @Rho-Studio architecture standard for Android mobile apps.

As business logic complexity grows, direct ViewModel-to-Repository interaction is being transitioned to a dedicated Domain Layer.

  • Use Cases (Interactors): Classes like LoginUseCase.kt (core/domain/usecase/LoginUseCase.kt) encapsulate specific business rules, making the logic reusable across different ViewModels and testable in isolation.

  • Business Transaction Flow: A single user action (e.g., "Login") may involve multiple steps: credential validation -> token acquisition -> user profile synchronization. These are managed as atomic transactions within the Domain Layer.

Consider

  1. MVVM.
  2. Single-activity host.
  3. Jetpack compose.
  4. Compose Navigation.
  5. @Rho-Studio UI colors.

Rho.Studio® - Engineering Department - Contact alexis.tercero@rho.studio

Activity

  1. moved this from Backlog to In progress in UI-Rho-Studio-Componentson Jul 31, 2026
  2. AlexisTercero55 commented on Jul 31, 2026

    @AlexisTercero55
    Collaborator

    Implementation Plan: Domain Layer & Modular Transition Strategy

    Introduce a dedicated Domain Layer and establish a modular package foundation for the Rho Studio UI application. This plan executes on the "Path to Enterprise-Grade Architecture" defined in the README.md, moving from a single-module Gradle structure toward a decoupled, multi-module architecture.

    Project Description & Goal

    Rho Studio UI is a modern Android application built with Jetpack Compose and MVVM following a Single-Activity Architecture.

    The goal of this task is to implement a Modular Transition Strategy:

    1. Consolidate Business Logic: Move business rules from the ViewModel and Data layers into a dedicated Domain Layer.
    2. Prepare for Multi-Module Gradle: Reorganize the current internal package structure within the :app module to mirror a future multi-module setup (e.g., :core:domain, :core:data, :feature:auth). This ensures that the eventual split into separate Gradle modules is a low-risk, structural change.
    3. Support Reactive Navigation: Utilize the Domain Layer as the catalyst for routing. Use Cases drive session state changes in SessionManager, which MainActivity observes to perform reactive Compose Navigation transitions.

    Dev team review Required

    Important

    Internal Modularization: We will reorganize the internal core and feature packages to strictly respect the boundaries of a multi-module architecture. The domain layer will be designed to be framework-independent (pure Kotlin), making it ready for a future :core:domain module split.

    Note

    UDF & Navigation: ViewModels and Use Cases will not hold references to the NavController. They will only mutate state, while MainActivity remains the sole orchestrator of navigation, responding to the Domain-driven session state.

    Proposed Changes

    [Architectural Reorganization]

    Restructure the internal packages to align with the Modular Transition Strategy.

    [REORGANIZE] com.rho.studio.ui.core

    • Move repository and manager into com.rho.studio.ui.core.data (Future :core:data).
    • Move model (pure data entities like User) into com.rho.studio.ui.core.domain.model (Future :core:domain).
    • Create com.rho.studio.ui.core.domain.usecase for framework-independent business logic.

    [Core: Domain Layer]

    Implement the "Interactors" as the new home for all business rules.

    [NEW] Result.kt

    • Standardized success/failure wrapper for Use Cases.

    [NEW] LoginUseCase.kt

    • Atomic Business Transaction:
      1. Validate input using the Credentials domain model.
      2. Execute authentication via the Data layer.
      3. Apply Domain transformations (e.g., name formatting).
      4. Commit the session state to the Single Source of Truth (SessionManager).

    [NEW] LogoutUseCase.kt

    • Atomic termination of user session, triggering the reactive navigation flow.

    [Core: Data Layer]

    Refine data components to serve as the implementation detail for the Domain layer.

    SessionManager.kt

    • State Responsibility: Act as the Single Source of Truth for observation.
    • API Evolution: Add internal updateSession(user: User) and clearSession() methods; deprecate old business-logic-heavy login/logout methods.

    [Feature Integration]

    Refactor UI features to depend on the Domain Layer for all actions.

    MainActivity.kt

    • Continues to observe the SessionManager state to handle reactive navigation transitions (Login <-> Home).

    LoginViewModel.kt

    • Replace direct manager calls with LoginUseCase.
    • Focus purely on UI state management and immediate feedback validation.

    HomeViewModel.kt

    • Use LogoutUseCase to trigger session termination.

    Verification Plan

    Automated Tests

    • Run ./gradlew test to ensure zero regression.
    • NEW: Unit tests for Use Cases in core.domain.usecase to verify atomic business rules and identity transformations.

    Manual Verification

    • Reactive Navigation: Verify that successful login/logout via Use Cases correctly triggers the MainActivity navigation flow.
    • Modular Boundary Audit: Verify that no feature ViewModels directly access SessionRepository or bypass the Use Case layer for state mutation.
    • Logcat Verification: Confirm the atomic transaction steps in LoginUseCase.
  3. moved this from In progress to In review in UI-Rho-Studio-Componentson Aug 7, 2026
  4. linked a pull request that will close this issuePre release v102 Done #34on Aug 11, 2026
  5. moved this from In review to In progress in UI-Rho-Studio-Componentson Aug 11, 2026
  6. linked a pull request that will close this issueRelease v1.0.2 - Rho Studio UI #35on Aug 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

Domain layerUse cases of business flowModuleGradlew multi-module project

Projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions