PLAN | Domain Layer & Use Case Implementation

[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

[AlexisTercero55]

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.