Questions concernant la conception axée sur le domaine

Question

Après avoir lu la conception axée sur le domaine d'Eric Evans, j'ai quelques questions. J'ai cherché mais pas où je pourrais trouver des réponses satisfaisantes. S'il vous plaît laissez-moi savoir si quelqu'un d'entre vous a une compréhension claire ci-dessous des questions.

Mes préoccupations sont

1. Repository est pour obtenir des agrégats déjà existants de DB, service Web. Si oui, peut Repository également transaction fait appel à cette entité (quantité de transfert, envoyer les détails du compte ... etc)

2. entité peut avoir des méthodes qui ont une logique métier dans lequel il appelle les services d'infrastructure de couche pour envoyer des e-mails. .logs etc (Méthodes d'entité appelant la direclty des services IS).

3. L'implémentation du référentiel et les classes Factory se trouvent dans la couche Infrastrucure. est-ce la bonne déclaration?

4. Une couche d'interface utilisateur (contrôleur) peut-elle appeler des méthodes de référentiel directement? ou devrions-nous les appeler à partir de la couche Application?

Il y a encore beaucoup beaucoup de confusion dans mon esprit ... s'il vous plaît me guider ... Livres J'UTILISE domaine Driven Eric Evan desing ...... Domain-Driven Design .NET avec C#

Answer 1

1. Il y a beaucoup de débats quant à savoir si les dépôts doivent être en lecture seule ou autoriser les transactions. DDD ne dicte aucune de ces vues. Vous pouvez faire les deux. Les partisans des référentiels en lecture seule préfèrent l'unité de travail pour toutes les opérations de la CUD.

2. La plupart des gens (inclus) considèrent qu'il est bon que les entités soient persistantes-ignorantes. L'extension de ce principe indiquerait qu'ils devraient être autonomes et dépourvus de tous les services de la couche d'infrastructure, même sous une forme abstraite. Donc, je dirais que les appels aux services d'infrastructure appartiennent aux classes de service qui fonctionnent sur les entités.

3. Il semble correct que les implémentations de Repository et les Factories (le cas échéant) doivent résider dans la couche d'infrastructure. Leurs interfaces, cependant, doivent résider dans la couche de domaine afin que les services de domaine puissent interagir avec eux sans avoir de dépendances sur la couche d'infrastructure. DDD ne dicte pas vraiment si vous pouvez ignorer les calques ou non. Tard dans le livre, Evans parle un peu de la superposition et l'appelle Relaxed Layering quand vous le permettez, alors je suppose qu'il le voit juste comme une option parmi plusieurs. Personnellement, je préfère éviter le saut de couche, car il est plus facile d'injecter un comportement à un moment ultérieur si les appels passent déjà par les couches correctes.

Answer 2

1. Personnellement, dans mon dernier projet DDD, j'utilise une unité de travail qui tient une session NHibernate. Le UoW est injecté dans les dépôts, en leur donnant le seul responsable de Ajouter, Retirer et Trouver.

2. Evans a déclaré qu'une partie du puzzle qui manque dans le livre DDD est «Domain Events». L'utilisation de quelque chose comme Udi Dahan's DomainEvents vous donnera une architecture totalement découplée (l'objet domaine soulève simplement un événement).Personnellement, j'utilise une version modifiée de Domain Events et StructureMap pour le câblage. Cela fonctionne très bien pour mes besoins.

3. Je recommande, en fonction d'autres recommandations, que les interfaces Repository fassent partie du modèle et que leurs implémentations fassent partie de l'infrastructure.

4. Oui! J'ai personnellement travaillé sur trois projets Web DDD où des services et des référentiels ont été injectés aux présentateurs/contrôleurs (ASP.NET/ASP.NET MVC) et cela a fait beaucoup de sens dans notre contexte.

Answer 3

1. Le référentiel ne doit être pour la localisation et les entités d'économie, il ne devrait pas y avoir de logique métier dans cette couche. Par exemple:

   repository.TransferAmount (amount, toAccount); // ceci est incorrect

2. Les entités peuvent faire des choses comme envoyer des emails tant qu'elles dépendent des abstractions définies dans votre domaine. L'implémentation doit être dans votre couche d'infrastructure. Oui, vous mettez votre implémentation de référentiel dans votre couche d'infrastructure.

3. Une couche d'interface utilisateur (contrôleur) peut-elle appeler des méthodes de référentiel directement? ou devrions-nous les appeler à partir de la couche Application?

Oui, j'essaie de suivre ce modèle pour la plupart:

[UnitOfWork] 
public ActionResult MyControllerAction(int id) 
{ 
    var entity = repository.FindById(id); 
    entity.DoSomeBusinessLogic(); 
    repository.Update(entity); 
}