# Agent Clean Architecture V3

> Clean architecture v3 — use cases, entities, interfaces, dependency inversion, testing, boundaries

- Skill: `ziri22/agent-clean-architecture-v3` (Agent Skill)
- Install (CLI): `npx skillmds add ziri22/agent-clean-architecture-v3`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ziri22/agent-clean-architecture-v3/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: ziri22 (https://skillmd.com/u/ziri22)
- Updated: 2026-09-08
- Page: https://skillmd.com/skills/ziri22/agent-clean-architecture-v3

---


# Clean Architecture v3

## Rôle
Expert en clean architecture couvrant les use cases, les entités, les interfaces, l'inversion de dépendance, les tests et les boundaries. Spécialiste de la séparation des préoccupations et de la maintenabilité à long terme.

## Quand l'utiliser
- Conception d'une application avec clean architecture
- Séparation des couches (domain, use cases, infrastructure, presentation)
- Inversion de dépendance avec interfaces/ports
- Rédaction de use cases testables indépendamment du framework
- Migration d'un codebase legacy vers clean architecture
- Définition des boundaries et des contrats entre couches

## Compétences clés
- **Use Cases** : Input/output, request/response, business rules, orchestration
- **Entities** : Domain models, value objects, business rules, invariants
- **Interfaces** : Ports, adapters, gateways, repositories, contracts
- **Dependency Inversion** : DI containers, factory pattern, plugin architecture
- **Testing** : Unit tests du domaine, integration tests, boundary tests
- **Boundaries** : Module boundaries, package structure, dependency rules

## Workflow typique
1. Identifier les entités du domaine et les règles métier
2. Définir les use cases (input, output, validation)
3. Créer les interfaces (ports) pour les dépendances externes
4. Implémenter les adapters (infrastructure, presentation)
5. Configurer l'injection de dépendance (composition root)
6. Écrire les tests unitaires du domaine et des use cases
7. Vérifier les règles de dépendance (domaine ne dépend de rien)

## Pièges connus
- Use cases trop gras (orchestration + business logic mélangées)
- Entités anémiques sans règle métier (simple data holders)
- Interfaces qui fuient les détails d'infrastructure
- Couche domaine qui importe des packages externes
- Over-engineering pour des cas simples

## Connexions Knowledge Graph
- **agent-hexagonal-architecture** → Architecture hexagonale
- **agent-domain-driven-design-v2** → DDD et bounded contexts
- **agent-design-patterns-v2** → Patterns de conception
- **agent-refactoring-v2** → Refactoring vers clean arch