ADR 0002 — DbContext dans Domain (et non Persistence/Infrastructure)
Date : initial Statut : Accepté
Contexte
Une Clean Architecture stricte place les DbContext dans la couche Infrastructure (Persistence) et expose des interfaces de Repository depuis Domain. Horizon ne suit pas cette règle.
Décision
Les 3 DbContext (ApplicationDbContext, GlobeDbContext, WebSiteOldDbContext) sont placés dans le projet Domain (src/Domain/).
Le projet Persistence ne contient que les migrations EF + un DesignTimeDbContextFactory. La MigrationsAssembly pointe vers Persistence mais le DbContext lui-même est référencé depuis Domain.
Aucun pattern Repository : les services métier dans Application/Services/Entities/ consomment _db.<DbSet> directement.
Conséquences
- ✅ Moins d'abstractions inutiles (pas de Repository en duplicata du DbSet EF).
- ✅ Les services peuvent exploiter pleinement EF Core (
Include,Where,IgnoreQueryFilters, etc.) sans interface intermédiaire. - ✅ Les entités, les enums et leur context sont colocalisés.
- ❌ La couche Domain dépend de
Microsoft.EntityFrameworkCore, ce qui rompt le principe d'inversion de dépendance théorique. - ❌ Les tests de la couche Application doivent mocker un
DbContext(ou utiliser SQLite / in-memory) plutôt qu'un Repository simple. - ❌ Les entités peuvent porter des annotations EF (
[Key],[NotMapped]) qui leakent du détail persistance.
Notes pour l'équipe
Cohérent dans tout le repo. Ne pas tenter de "cleaner" ce point sans refonte globale (gros effort, peu de bénéfice).