Repository Pattern & Data Layer Governance

Context & Principles

The Data Layer is responsible for handling business logic and application data. The Repository Pattern abstracts data sources (network, database, files) from the rest of the app. This skill enforces rules for building Repositories based on Google's official Data Layer guidelines and Clean Architecture reference implementations (such as NowInAndroid).

Core Architecture Rules

1. Separation of Concerns: The Data Layer must be completely decoupled from the UI Layer. ViewModels should only interact with the Data Layer through interfaces defined in the Domain Layer.
2. Clean Architecture Boundaries:
   • Domain Module: Defines the contract (Interface), domain models, and typed domain errors (DomainError). Must NOT contain Android framework dependencies (like Retrofit, Room, or Ktor), nor should it know about technical exceptions or data source implementation details.
   • Data Module: Implements the repository interface. Handles data sources (Network/Local), entity mapping (DTOs/Entities to Domain models), and exception translation (Throwable -> DomainError).
3. Single Source of Truth (SSOT): The local database or cache should ideally act as the SSOT. The repository should expose this truth via reactive streams, avoiding returning data directly from the network when offline capabilities or local state (like isFavorite) are required.
4. Typed Domain Errors vs. Naked Exceptions: Never leak technology-specific exceptions (HttpException, SQLiteException, IOException) into the Domain or UI layers. The Data Layer MUST translate technical framework exceptions into typed domain errors (DomainError).
5. Concurrency: All operations must be main-safe. Use Kotlin Coroutines (suspend) for one-shot operations and Flow for continuous data streams.

Instructions for Agents

When generating or refactoring a Repository or Data Layer, you MUST follow these steps. For implementation details, consult the appropriate reference file in the references/ directory.