J'ai pratiqué DDD pendant un moment avec les 4 couches distinctes: domaine, présentation, application et infrastructure. Récemment, j'ai introduit un de mes amis au concept DDD et j'ai pensé qu'il a introduit une couche de complexité inutile (spécifiquement ciblant les interfaces et le CIO). Habituellement, c'est à ce stade, j'explique les avantages du DDD- - en particulier, sa modularité. Toutes les lourdes levées et sous la hotte se trouvent dans l'infrastructure et si je voulais modifier complètement la méthode d'accès aux données sous-jacentes, je ne pouvais donc pas avoir à toucher le référentiel de calques d'infrastructure.
L'argument de mon ami est qu'il pourrait construire une application à trois niveaux de la même manière:
Il créerait des modèles commerciaux (comme des modèles de domaine) et que les référentiels dans la couche de données renvoient ces modèles commerciaux. Ensuite, il appellerait la couche d'entreprise qui appelait la couche de données. Je lui ai dit le problème de cette approche, c'est qu'il n'est pas testable. Bien sûr, vous pouvez écrire des tests d'intégration, mais vous ne pouvez pas écrire des tests d'unités réels. Pouvez-vous voir d'autres problèmes avec son approche proposée à 3 niveaux (je sais qu'il y en a, parce que pourquoi DDD existerait-il autrement?).
Edit: il n'utilise pas le CIO. Chaque couche dans son exemple dépend de l'autre.
3 Réponses :
Je pense que vous mélangez quelques méthodologies. DDD est développé sur le domaine et consiste à faire du domaine commercial une partie de votre code. Ce que vous décrivez les sons plus semblables à l'architecture d'oignon ( lien ) contre une approche «normale» à 3 couches. Il n'y a rien de mal à utiliser une architecture à 3 couches avec DDD. DDD dépend de TDD (Développement Testdriven). Les interfaces aident avec TDD car il est plus facile de tester chaque classe d'isolement. Si vous utilisez l'injection de dépendance (et le CIO), il est encore atténué.
L'architecture d'oignon consiste à faire du domaine (A.K.A. Règles commerciales) indépendamment de tout le reste - c'est-à-dire. C'est le cœur de l'application avec tout en fonction des objets et des règles de l'entreprise, tandis que des éléments liés à l'infrastructure, à l'interface utilisateur et ainsi de suite sont dans les couches extérieures. L'idée est que le module «Shell de l'oignon» est-il plus proche de la «coquille de l'oignon». Il est facile de échanger une nouvelle mise en œuvre.
J'espère que cela l'effache un peu haut - maintenant avec une modification mineure!
Hmmm ... Je connais très bien l'architecture d'oignon de Jeff Palermo, car mon projet a ces couches distinctes en elle et je l'ai basée autour de son poste de blog. Cependant, toutes ces couches existent également dans un projet DDD également (par exemple domaine, application, présentation et infrastructure).
Mon point était que, bien que la structure de l'Union soit utilisée par beaucoup qui utilise également DDD - ce n'est pas une condition préalable à DDD.
Pour élaborer davantage - à pratiquer DDD - vous n'avez pas besoin d'un ensemble spécifique de couches et ne doivent pas nécessairement être structurés de manière spécifique. Cependant, tout ce que vous avez codé doit modéliser le domaine que vous ciblez, y compris des objets métier ayant les mêmes noms que leurs homologues réels.
Pourtant, la différence est que dans l'approche à 3 couches que j'ai décrite, sans utiliser de CIO, est que chaque couche sait et dépend de l'autre ... N'est-ce pas un anti-motif?
Ce n'est pas un anti-motif en soi, mais je conviens que l'utilisation de la structure d'oignon rend le couplage à lâche lorsque la couche d'entreprise n'est pas dépendante de la couche d'infrastructure. Je préfère beaucoup l'oignon sur le modèle traditionnel à 3 couches. Mais je crois toujours qu'il est pleinement possible d'utiliser une architecture à 3 couches si vous ne croyez pas à l'échange de parlement. votre ormes: voir ce lien pour pourquoi: ayende.com/blog/archive/2010/07/30/...
L'utilisation d'un conteneur CIO est un compromis, car elle introduit une complexité pour le couplage plus souple. Tout est à propos de ce dont vous avez besoin. Edit: et vous pouvez toujours utiliser des interfaces et une injection de dépendance entre vos couches dans une architecture à 3 couches pour faciliter les tests.
Je commence à comprendre où vous venez de ... Si vous modifiez votre réponse, je peux changer mon vote.
Je pense que vous comparez des pommes et des oranges. Rien à propos de N-Tier l'interdit d'utiliser des interfaces et des diologies pour être facilement testé unitaire. De même, DDD peut être effectué avec des classes statiques et des dépendances rigoureuses.
En outre, s'il met en œuvre des objets métier et en utilisant des référentiels, on dirait qu'il fait du DDD, et que vous avez un peu plus de sémantique.
Êtes-vous sûr que le problème n'est pas simplement à l'aide de DI / IOC ou non?
Comment quelque chose peut-être facilement être testé sans utiliser IOC? Il peut avoir des tests d'intégration, mais comment faire des tests de l'unité sans interfaces / ioc / di?
Ce que je dis, c'est que DDD ou N-Tier n'impliquent pas le CIO ou non. Il semble que vous essayiez de concentrer la question sur DDD vs. N-Tier, mais quelle est votre question qui semble vraiment demander est IOC / DI vs. No CIO / DI. Fwiw, je serais sur votre côté Soutenir le CIO / DI. Je ne pense tout simplement pas que DDD ou N-Tier sont pertinents du tout, puisque peut être fait avec ou sans DI / IOC.
N TIER ou dans ce cas, l'architecture 3 niveaux fonctionne bien avec des tests unitaires. Tout ce que vous avez à faire est le CIO (inversion du contrôle) à l'aide d'une injection de dépendance et d'un motif de référentiel.
La couche d'entreprise peut valider et préparer les données retournées pour la couche de présentation \ Web API en renvoyant les données exactes requises. Vous pouvez ensuite utiliser des tests de maquette dans vos appareils à travers les couches. Toute votre logique et vos besoins professionnels peuvent être sur la couche BL. Et la couche dal contiendront des référentiels injectés du niveau supérieur.
La conception et l'architecture à plusieurs niveaux de domaine ne semblent pas vraiment être pertinentes pour votre différend (et comme je les comprends, ils sont orthogonaux les uns envers les autres). Si vous vous décollerez les acronymes, qu'est-ce que vous êtes vraiment en désaccord? Codage aux interfaces et à l'injection de dépendance?
"Edit: il n'utilise pas ioc. Chaque couche dans son exemple dépend de l'autre." Peut toujours utiliser Mockito pour tester. Donc, ce n'est pas l'un ou l'autre. Plus sur ce que l'un ou un groupe perçoit comme plus propre, bien conçu et plus facile à entretenir (comme un niveau comparatif, pas que le code potentiellement non restauble)