Beaucoup de tutoriels sur DDD que j'ai étudiés couvrent principalement la théorie. Ils ont tous des exemples de code rudimentaires (Pluralsight et similaires).
Sur le Web, quelques personnes tentent également de créer des didacticiels couvrant DDD avec EF. Si vous commencez à les étudier brièvement - vous remarquez rapidement qu'ils diffèrent beaucoup les uns des autres. Certaines personnes recommandent de garder l'application minimale et d'éviter d'introduire des couches supplémentaires, par exemple un référentiel au-dessus d'EF , d'autres génèrent décidément des couches supplémentaires, souvent même en violant SRP en injectant DbContext
dans les racines d'agrégat.
Je m'excuse terriblement si je pose une question d'opinion, mais ...
En matière de pratique, Entity Framework est l'un des ORM les plus puissants et les plus utilisés. Malheureusement, vous ne trouverez pas de cours complet couvrant DDD.
Aspects importants:
Entity Framework sort UoW & Repository (
DbSet
) de la boîteavec EF vos modèles ont des propriétés de navigation
avec EF tous les modèles sont toujours disponibles off
DbContext
(ils sont représentés comme unDbSet
)
Pièges:
vous ne pouvez pas garantir que vos modèles enfants sont uniquement affectés via la racine agrégée - vos modèles ont des propriétés de navigation et il est possible de les modifier et d'appeler
dbContext.SaveChanges()
avec
DbContext
vous pouvez accéder à chacun de vos modèles, contournant ainsi la racine agrégéevous pouvez restreindre l'accès aux enfants de l'objet racine via la méthode
ModelBuilder
in en les marquant comme des champs - je ne pense toujours pas que ce soit la bonne façon de faire à propos de DDD et il est difficile d'évaluer le type d'aventures que cela pourrait conduire à l'avenir ( assez sceptique) )OnModelCreating
Conflits:
sans implémenter une autre couche de référentiel qui renvoie Aggregate, nous ne pouvons même pas résoudre en partie les pièges susmentionnés
en implémentant une couche supplémentaire de référentiel, nous ignorons les fonctionnalités intégrées d'EF (tout
DbSet
est déjà un dépôt) et compliquons trop l'application
Ma conclusion:
Veuillez excuser mon ignorance, mais sur la base des informations ci-dessus - c'est soit Entity Framework n'est pas adéquat pour la conception pilotée par domaine ou la conception pilotée par domaine est une approche imparfaite et obsolète .
Je soupçonne que chacune des approches a ses mérites, mais je suis complètement perdu maintenant et je n'ai pas la moindre idée de la façon de réconcilier EF avec DDD.
Si je me trompe - quelqu'un pourrait-il au moins détailler un simple ensemble d'instructions (ou même fournir des exemples de code décents) sur la façon de traiter DDD avec EF, s'il vous plaît?