layered-module-patterns

Clean architecture domain and data boundaries are enforced by keeping contracts and abstract use cases in domain modules, while repositories, sources, mappers, and Koin bindings stay strictly in data modules. This separation prevents module-architecture drift and ensures feature layers only consume interactor aliases.

Offline-first paging with Room requires using Room-backed observable flows as the source-of-truth for paged and non-paged data. You must coordinate paging refresh logic correctly and ensure mapper ownership stays within the data layer to maintain data consistency.

Feature and task modules should consume interactor aliases specialized with DataState to keep a lean Types.kt file. This discipline allows safe import boundaries, letting features invoke use cases without directly accessing underlying repositories, sources, or remote models.

Selecting the correct layered module pattern involves matching query-only, hybrid query+mutation, mutation-only, and Android platform support scenarios to the closest reference layout. This ensures consistent wiring for feature, data, domain, and task modules across your project.

Importing repositories, sources, mappers, or remote models into feature layers breaks safe import boundaries and causes module-architecture drift. Feature and task layers must only import interactor aliases from Types.kt to maintain proper domain-data separation.

Koin dependency injection works with operation-specific repository contracts by binding those repository implementations within the data layer. This domain-driven design approach ensures feature layers receive dependencies through lean interactor aliases without direct repository access.