J'ai du mal à tracer une ligne claire entre la couche Présentation et Application dans la conception pilotée par domaine.
Où les contrôleurs, les vues, les mises en page, les fichiers Javascript et CSS doivent-ils aller?
Est-ce dans la couche Application ou Présentation?
Et s'ils vont tous ensemble dans la même couche, que contient l'autre? Est-il vide?
Réponses:
Ce n'est pas parce que quelqu'un a créé et nommé "Couche d'application" et "Couche de présentation" que votre application devrait en avoir. Vous devez créer des couches APRÈS avoir créé une quantité substantielle de code que vous avez regroupée et que vous souhaitez nommer ce groupe pour des raisons de communication entre les développeurs et de clarté du code.
Du point de DDD. La couche application est tout ce qui n'est pas la couche domaine. Ce qui inclut la logique d'application, la présentation et les services d'application.
Il existe une grande différence entre la couche application et la couche présentation d'un point de vue DDD.
Bien que DDD se concentre sur la façon de modéliser le domaine à l'aide des blocs de construction DDD et des concepts tels que les contextes limités, le langage omniprésent et ainsi, il est toujours essentiel d'identifier clairement et de séparer les différentes couches de votre application.
L'architecture joue un grand rôle dans la mise en œuvre d'une application DDD réussie. Une architecture célèbre qui a gagné beaucoup de battage publicitaire récemment est l'architecture de l'oignon:
Dans cette conception, la couche d'interface utilisateur / présentation et la couche d'application sont clairement séparées. La fusion des 2 introduit un couplage étroit entre 2 couches qui ont des préoccupations et des responsabilités clairement distinctes.
La couche Présentation ne doit contenir que la logique de présentation. Évitez les interfaces utilisateur intelligentes qui en savent trop. Cela héberge principalement les contrôleurs et les vues du MVC en plus du CSS, du JS, des modèles, des formulaires et tout ce qui concerne les objets de réponse et de demande.
Les actions émises via la présentation sont déléguées à la couche application via des commandes. La couche application contient la logique d'application. Il correspond normalement à un cas d'utilisation. Il contient ce que le système doit faire pour satisfaire un cas d'utilisation. Un service d'application typique demandera à un référentiel de renvoyer un agrégat puis invoquera une action sur cet agrégat.
Jetez un œil à l'exemple de projet de l'IDDD de Vaughn Vernon
entry pointet composition rootplacés? J'ai toujours pensé que c'était une responsabilité de Applicationcouche. Mais maintenant, il semble que ce soit un Presentationcalque.
La conception pilotée par le domaine n'a rien à voir avec la couche Présentation ou la couche Application. DDD est une méthodologie dont l'objectif principal est la couche Domaine. Autrement dit, DDD n'impose aucune contrainte concernant une autre couche, à l'exception de la couche Domaine et Votre question pourrait également être posée dans le contexte de toute autre méthodologie.
Cela étant dit, il est très courant d'utiliser une architecture à quatre couches pour les applications DDD. Voici un exemple d'une telle application montrant les couches et leur utilisation prévue: DDDSample Architecture . Donc, si vous choisissez d'utiliser cette architecture, vos vues et mises en page iront à la couche Interfaces et les contrôleurs, s'ils sont indépendants de l'interface, iront à la couche Application.
Vous pourriez aussi bien choisir n'importe quel autre type d'architecture, comme je l'ai dit, DDD n'impose pas de contraintes. Il existe de nombreux frameworks MVC qui ont des structures différentes et qui pourraient néanmoins être utilisés pour les applications DDD. Ensuite, bien sûr, vous placeriez vos vues et mises en page en conséquence.