Couche application vs couche domaine?
Je lis Domain-Driven Design par Evans et je suis en train de discuter de l'architecture en couches. Je viens de réaliser que les couches d'application et de domaine sont différentes et devraient être séparées. Dans le projet sur lequel je travaille, ils sont en quelque sorte mélangés et je ne peux pas faire la différence avant d'avoir lu le livre (et je ne peux pas dire que c'est très clair pour moi maintenant), vraiment.
Mes questions, puisque les deux concernent la logique de l'application et sont censées être dépourvues d'aspects techniques et de présentation, quels sont les avantages de tracer une frontière entre ces deux?
J'ai récemment lu DDD moi-même. Quand je suis arrivé dans cette section, j'ai été agréablement surpris de découvrir que j'ai découvert la même architecture à 4 couches qu'Evans. Comme l'a souligné @lonelybug, la couche de domaine doit être complètement isolée du reste du système. Cependant, quelque chose doit traduire des valeurs spécifiques à l'interface utilisateur (chaînes de requête, POST, session, etc.) en objets de domaine. C'est là que la couche d'application entre en jeu. Son travail consiste à traduire dans les deux sens entre l'interface utilisateur, la couche de données et le domaine, cachant efficacement le domaine du reste du système.
Je vois maintenant beaucoup d'applications ASP.NET MVC où presque toute la logique est dans les contrôleurs. Il s'agit d'une tentative infructueuse de mise en œuvre de l'architecture classique à 3 couches. Les contrôleurs sont difficiles à tester unitairement car ils ont de nombreuses préoccupations spécifiques à l'interface utilisateur. En fait, écrire un contrôleur de manière à ce qu'il ne soit pas directement concerné par les valeurs du "contexte Http" est un défi en soi. Idéalement, le contrôleur devrait simplement effectuer la traduction, coordonner le travail et recracher la réponse.
Il peut même être judicieux d'effectuer une validation de base dans la couche application. Il est normal que le domaine suppose que les valeurs qui y entrent ont un sens (est-ce un ID valide pour ce client et cette chaîne représente-t-elle une date/heure). Cependant, la validation impliquant la logique métier (puis-je réserver un billet d'avion dans le passé?) Doit être réservée à la couche domaine.
Martin Fowler commente en fait comment la plupart des couches de domaine sont plates ces jours-ci . Même si la plupart des gens ne savent même pas ce qu'est une couche d'application, il constate que beaucoup de gens créent des objets de domaine plutôt stupides et des couches d'application complexes qui coordonnent le travail des différents objets de domaine. J'en suis moi-même coupable. L'important n'est pas de créer un calque car un livre vous l'a dit. L'idée est d'identifier les responsabilités et de séparer notre code en fonction de ces responsabilités. Dans mon cas, la "couche d'application" a évolué naturellement lorsque j'ai augmenté les tests unitaires.
Reprenant les modèles de conception d'entreprise de Martin Fowler, les couches les plus courantes sont:
Présentation - ce sont des vues, des modèles de présentation qui génèrent l'interface d'interaction pour votre application (j'utilise l'interaction dans le cas où votre application est accédée par d'autres systèmes via des services Web ou RMI donc peut ne pas être une interface utilisateur). Cela inclut également les contrôleurs qui décident comment les actions seront exécutées et comment.
Domaine - c'est là que résident vos règles et votre logique métier, vos modèles de domaine sont définis, etc.
Source de données - il s'agit de la couche de mappage de données (ORM) et de la source de données (base de données, système de fichiers, etc.)
Comment dessinez-vous les limites entre les trois couches:
Ne placez pas de logique de présentation spécifique dans vos modèles ou objets de domaine
Ne placez pas de logique dans vos pages et contrôleurs, c'est-à-dire une logique pour enregistrer des objets dans la base de données, créer des connexions à la base de données, etc., ce qui rendra votre couche de présentation fragile et difficile à tester
Utilisez un ORM qui vous permet de dissocier votre accès à la source de données et vos actions du modèle
Suivez le paradigme du contrôleur mince - modèle gras, les contrôleurs sont pour contrôler le processus d'exécution sans le réaliser, plus sur http://www.littlehart.net/atthekeyboard/2007/04/27/fat-models- skinny-controllers / et http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model modèle, vue et contrôleur,
La couche de domaine modélise la entreprise de votre application. Cela devrait être votre interprétation claire de ses règles, de sa dynamique de composants et contient son état à un moment donné.
couche d'application est "inquiet" de définir les tâches à effectuer pour accomplir une certaine tâche d'application. Principalement, il est chargé de mandater le travail de domaine nécessaire et interagit avec d'autres services (externes ou non).
Pour exemple, mon application financière a une opération utilisateur pour changer l'état d'une entité modèle (entité telle que définie dans DDD [89]):
- "Le chef des opérations peut approuver une proposition financière".
Mais, en tant que processus d'application, outre toutes les conséquences du modèle de cette opération, je dois envoyer une communication interne aux autres utilisateurs de l'application. Ce type de travail est "orchestré" dans la couche application. Je ne voudrais pas que ma couche de domaine pense à diriger un service de messagerie. (et ce n'est certainement pas une responsabilité de la couche présentation). Quoi qu'il en soit, une chose est sûre: j'ai besoin d'une nouvelle couche car ma couche de domaine concerne tout le cœur de métier et ma couche de présentation est tout sur l'interprétation des commandes utilisateur et la présentation des résultats.
Remarques:
- Business est l'un de ces mots qui mènent fréquemment à de multiples interprétations de sa signification, mais vous pouvez certainement trouver de nombreux exemples et parler de DDD;
- DDD signifie Domaine-Driven Design livre par Eric Evans et numéro entre crochets pour le numéro de page.
La couche de domaine doit être conçue comme une couche d'isolation, ce qui signifie que la logique métier et les règles ne doivent pas être affectées par des modifications de codes (dans la couche application, la couche présentation et la couche infrastructure).
La couche d'application est censée être conçue pour fournir certaines fonctions sur ce qu'une interface système (application) (pensez à cela comme une API ou RESTful) peut faire. Par exemple, les utilisateurs peuvent se connecter à un système et, dans cette action d'application (connexion), les codes de couche d'application seront les codes client pour la couche de domaine (ou la couche d'infrastructure), dans lesquels récupère l'objet de domaine utilisateur et applique les méthodes de cet objet pour implémenter le fonction "connexion".
La couche d'application doit également être conçue comme une couche d'isolement, ce qui signifie que les comportements de l'application ne doivent être affectés par aucun changement de code (dans la couche de présentation, la couche de domaine et la couche d'infrastructure).
- La couche application et la couche domaine relèvent toutes deux de la portée de l'implémentation.
- La couche application agit comme une API.
- La couche de domaine est une implémentation de l'API, elle contient la logique métier, elle est donc également appelée la couche logique métier.
Le point de la modélisation pilotée par domaine est de séparer le modèle de domaine essentiel et de le faire exister sans aucune dépendance sur d'autres couches et autres problèmes d'application.
Cela vous permet de vous concentrer sur le domaine lui-même sans distractions (comme la coordination entre l'interface utilisateur et les services de persistance).
La principale raison de ces limites est séparation des préoccupations . Le code qui accède au magasin de données ne devrait avoir à se soucier que d'accéder au magasin de données. Il ne devrait pas être responsable de l'application des règles sur les données. De plus, l'interface utilisateur devrait être responsable de la mise à jour des contrôles dans l'interface utilisateur, de l'obtention des valeurs de l'entrée utilisateur et de leur traduction en quelque chose que la couche de domaine peut utiliser, et rien de plus. Il doit appeler les opérations fournies par la couche domaine pour effectuer toutes les actions nécessaires (par exemple, enregistrer ce fichier). Un service Web appelé doit être responsable de la conversion du support de transmission en quelque chose que la couche de domaine peut utiliser, puis appeler la couche de domaine (la plupart des outils effectuent une grande partie de ce travail pour vous).
Cette séparation, lorsqu'elle est correctement mise en œuvre, peut vous permettre de modifier des parties de votre code sans affecter les autres. Par exemple, l'ordre de tri d'une collection d'objets retournée doit peut-être changer. Puisque vous savez que la couche responsable de la manipulation des données (généralement la couche de logique métier) gère ce genre de choses, vous pouvez facilement identifier où le code doit être changé. En plus de ne pas avoir à modifier la façon dont il est récupéré à partir du magasin de données ou de l'une des applications utilisant le domaine (l'interface utilisateur et le service Web de mon exemple ci-dessus).
Le but ultime est de rendre votre code aussi facile à maintenir que possible.
En guise de remarque, certaines choses ne peuvent pas être intégrées dans une couche spécifique du domaine (par exemple, la journalisation, la validation et l'autorisation). Ces éléments sont communément appelés préoccupations transversales et, dans certains cas, peuvent être traités comme une couche autonome que toutes les autres couches peuvent voir et utiliser.
Personnellement, je pense que l'approche en couches est dépassée et que l'approche des services est meilleure. Vous avez toujours la ligne dure tracée dans le sable pour savoir qui fait quoi, mais cela ne vous oblige pas à être aussi hiérarchique. Par exemple, un service de bon de commande, un service de facturation et un service d'expédition, du point de vue de l'application, tous ces services représentent votre domaine, et le report de responsabilité que j'ai décrit ci-dessus est toujours valable dans ce contexte, il vient d'être modifié tel que votre domaine existe à plusieurs endroits, en utilisant en outre le concept de séparation des préoccupations.