Services d'infrastructure DDD
Je suis en train d'apprendre DDD et je suis un peu perdu dans la couche de l'Infrastructure:
Que je comprends, "toutes les bonnes DDD applications" devrait avoir 4 couches: Présentation, Application, de Domaine et de l'Infrastructure. Base de données devrait être accessible à l'aide de Référentiels. Référentiel des interfaces doit être dans le Domaine de la couche d'un référentiel et de mise en œuvre - dans les Infrastructures (référence DDD: le cas de tenir des Interfaces de domaine, de l'Infrastructure?).
Application, le Domaine et la couche de l'Infrastructure doivent/peuvent avoir des services (référence www.lostechies.com/blogs/jimmy_bogard/archive/2008/08/21/services-in-domain-driven-design.aspx), dans l'exemple EmailService dans la couche de l'Infrastructure qui envoie des messages e-Mail.
MAIS, à l'intérieur de la couche de l'Infrastructure, nous avons référentiel implémentations, qui sont utilisés pour accéder à la base de données. Donc, dans ce cas, les référentiels sont des services de base de données? Quelle est la différence entre l'Infrastructure de service et de référentiel?
Merci d'avance!
source d'informationauteur Zygimantas
Vous devez vous connecter pour publier un commentaire.
Coller avec DDD définitions, un Référentiel est différent de celui d'un Service. Un Référentiel est directement corrélée à une Entité, souvent une Racine d'Agrégat. Un Service définit les comportements qui ne sont pas vraiment appartiennent à une Entité unique dans votre domaine. Vous pouvez tout à fait trouver des Services dans chaque couche, si les types de problèmes qu'il adresse diffèrent d'une couche à l'autre et peuvent être différents de DDD conceptuel du Service.
Lorsque l'on travaille au niveau conceptuel, un DDD Référentiel diffère de l'IA en ce qu'elle est spécifiquement lié à l'Entité de persistance. Un Service peut traiter de n'importe quel Domaine, de l'Application ou de l'Infrastructure problème que vous pourriez avoir.
Vous exécutez dans la terminologie des affrontements avec DDD tous sur la place. Par exemple, un DDD Référentiel n'est PAS la même chose que le Modèle de référentiel trouvé dans Martin Fowler PoEAA livre, bien qu'il puisse utiliser ce genre de modèle. C'est souvent une source de confusion pour de nombreuses personnes.
Il aide avec DDD si vous gardez toujours le Modèle de Domaine au centre de tout ce que vous faites. Quand il s'agit de la superposition DDD applications, j'ai souvent choisir Jeffrey Palerme Oignon Architecture. Check it out. Télécharger CodeCampServerun exemple d'application à l'aide de cette architecture. Je pense que c'est un ajustement parfait pour DDD programmation.
Bonne chance!
Un malheureux chose à propos de DDD est le mot "Service". Ce qu'il devrait être, c'est le Domaine de Service". Pensez au Domaine en tant qu'entités et des objets de valeur, alors que les Services sont un moyen de traiter avec les actions, opérations et activités.
Comme pour les Dépôts, ils ne sont qu'une façade qui devrait se comporter comme une collection à votre domaine. Si vous utilisez un ORM ou d'écrire votre propre, c'est ce que tous vos objets de domaine doit être en train de traverser pour atteindre la persistance, au lieu de ces services directement.
Peut-être que ça aidera à voir un projet potentiel de la structure.
Possible d'assemblage ou de la structure du package:
Projet.Domaine
Projet.L'Infrastructure.Les données
Projet.L'Infrastructure.Composants
Projet.L'Infrastructure.
Possible de l'espace de noms ou de structure de dossier:
Projet.Domaine
-n - Modules
----n - Compte
-------f - Compte.xx
-------f - AccountRepository.xx
-------f - Contact.xx
----n - Marketing
-------f - RegionRepository.xx
-n - Partagé
-n - Services
Projet.L'Infrastructure.De données (OU-Mappeurs)
-n - Tables
-n - Vues
-n - Procédures
-n - Fonctions
Projet.L'Infrastructure.Les Composants (Générique)
-n - Mail
-n - Cryptographie
-n - INTERFACE utilisateur
Projet.L'Infrastructure.Services (Opérations Spéciales)
-f - DoingSomethingService1.xx
-f - DoingSomethingService2.xx
-f - DoingSomethingService3.xx
Domaine des Entités et des Types de Valeur n'utilisez pas les Services de Domaine. La Couche Application utilise les Services de le Domaine. Le Domaine des objets du Référentiel utilisation de l'Infrastructure.Les objets de données à retourner des objets du Domaine.
Pourquoi voudriez-vous mettre référentiel des implémentations dans les Infrastructures ? Ils ne sont pas liés à "l'Infrastructure" à mon humble avis.
Selon Evan Livre Bleu de l'les dépôts sont une partie du modèle de domaine. Donc, j'ai mis le référentiel d'interface à l'intérieur du modèle de domaine. La mise en œuvre du référentiel parfois ainsi.
Infrastructure devrait contenir des "infrastructures" du code, ce qui pourrait être un service qui vous permet de recevoir des e-mail via smtp, ou un code qui résumés DB accès pour vous (ainsi, certaines classes que vous pouvez utiliser dans votre référentiel, mais il n'est pas de votre référentiel).
Ne mettez pas vos dépôts dans les "infrastructures", puisqu'ils n'appartiennent pas là.
Pour moi, les classes qui peuvent être trouvés dans les infrastructures , sont des classes que vous pouvez utiliser dans différents autres projets, voir ce que je veux dire ? Les Classes qui ne sont pas étroitement liés à votre domaine ou de modèle d'application appartiennent à l'Infrastructure. Et un référentiel de mise en oeuvre est assez étroitement couplé à une application spécifique. 🙂