repository-placement

Place repository interfaces in the use-case layer for Clean Architecture.

81|3|Updated Jan 14, 2026

Search Tags:#architecture #repository #clean-architecture #use-cases #domain-purity #interface-placement

Ready to run

npx skills add https://github.com/j5ik2o/okite-ai --skill repository-placement

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: repository-placement
Source: https://github.com/j5ik2o/okite-ai/tree/main/.agent/skills/repository-placement
Command: npx skills add https://github.com/j5ik2o/okite-ai --skill repository-placement

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Repository interfaces must be placed in the use-case layer to avoid coupling the domain model to persistence concerns and to enforce clean architectural boundaries.

Core Features & Use Cases

Provides guidance on where to locate repository interfaces in a Clean Architecture project.
Explains the consequences of placing interfaces in the domain layer and offers actionable patterns to relocate them.
Includes a practical scenario illustrating correct separation between domain, use cases, and interface adapters.

Quick Start

Move repository interface declarations into the use-case layer and adjust imports to prevent domain-models from importing persistence responsibilities.

Frequently Asked Questions about repository-placement

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

Why should repository interfaces be placed in the use-case layer instead of the domain layer in Clean Architecture?▼

Repository interfaces belong in the use-case layer to preserve domain purity by preventing domain models from importing persistence concerns. Placing them in the domain layer couples your core business logic to infrastructure dependencies, violating the intended dependency direction of Clean Architecture.

How do I move repository interfaces out of my domain models to enforce clean architectural boundaries?▼

To enforce clean architectural boundaries, move repository interface declarations into the use-case layer and adjust imports so domain models no longer reference repository contracts. This separation ensures domain logic remains independent of persistence responsibilities and infrastructure adapters.

What project structure do I need to properly separate domain models from repository contracts?▼

You need a project structure with separate domain/, usecases/, and interface-adapters/ directories. This layout allows repository interfaces to reside in the use-case layer while implementation details stay in interface adapters, ensuring domain models remain pure and free of persistence imports.

What happens if my domain layer imports repository interfaces in a Clean Architecture project?▼

If your domain layer imports repository interfaces, your domain models become coupled to persistence concerns, breaking domain purity. This violates Clean Architecture's dependency direction, making the core business logic harder to test and maintain independently of infrastructure changes.

How do I check if my domain models are incorrectly importing repository contracts?▼

You can check for incorrect imports by scanning your domain layer for references to repository contracts or interfaces. The Skill verifies that repositories are not imported into domain models and confirms interfaces are declared in the use-case layer to maintain proper architectural boundaries.

Can I use this approach for existing Clean Architecture projects that already have repositories in the domain layer?▼

Yes, existing Clean Architecture projects can relocate repository interfaces from the domain layer to the use-case layer. Adjust imports across domain models and interface adapters to enforce the correct dependency direction and restore domain purity without rewriting core business logic.