Couche d'application vs couche de domaine?

Je lis actuellement Domain-Driven Design de Evans et je discute de l’architecture en couches. Je viens de me rendre compte que les couches application et domaine sont différentes et doivent ê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 tant que je n'ai pas lu le livre (et je ne peux pas dire que c'est très clair pour moi maintenant), vraiment.

Mes questions, puisque toutes les deux concernent la logique de l'application et sont supposées être exemptes d'aspects techniques et de présentation, quels sont les avantages de tracer une limite entre ces deux?

J'ai récemment lu moi-même DDD. Quand je suis arrivé dans cette section, j'ai été agréablement surpris de découvrir que j'avais découvert la même architecture à 4 couches que celle d'Evans. Comme @lonelybug l'a souligné, la couche de domaine doit être complètement isolée du reste du système. Cependant, quelque chose doit traduire les valeurs spécifiques à l'interface utilisateur (chaînes de requête, données POST, session, etc.) en objets de domaine. C'est là que la couche d'application entre en jeu. Son travail consiste à effectuer des va-et-vient entre l'interface utilisateur, la couche de données et le domaine, en masquant efficacement le domaine au reste du système.

Je vois beaucoup d'applications ASP.NET MVC où presque toute la logique est dans les contrôleurs. Il s'agit d'une tentative infructueuse d'implémentation de l'architecture classique à trois couches. Les contrôleurs sont difficiles à tester, car ils ont de nombreuses préoccupations spécifiques à l’interface utilisateur. En fait, écrire un contrôleur de sorte qu'il ne soit pas directement concerné par les valeurs de "Contexte Http" constitue un défi de taille 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 assume que les valeurs qu'il contient ont un sens (s'agit-il d'un identifiant valide pour ce client et cette chaîne représente-t-elle une date / heure)? Cependant, la validation impliquant une logique métier (puis-je réserver un billet d'avion dans le passé?) Doit être réservée à la couche de domaine.

Martin Fowler commente à quel point la plupart des couches de domaine sont plates de nos jours . Même si la plupart des gens ne savent même pas ce qu'est une couche d'application, il constate que beaucoup de personnes 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. Je suis coupable de cela moi-même. L'important n'est pas de construire une couche, car un livre vous l'a dit. L'idée est d'identifier les responsabilités et de séparer votre code en fonction de ces responsabilités. Dans mon cas, le type "couche d'application" a naturellement évolué à mesure que j'augmentais le nombre de tests unitaires.

À partir des modèles de conception d’entreprise de Martin Fowler, les couches les plus courantes sont les suivantes:

• Présentation - Il s'agit de vues, de 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 serait accédée par d'autres systèmes via des services Web ou RMI et ne constituerait donc peut-être pas une interface utilisateur). Cela inclut également les contrôleurs qui décident de la manière dont les actions seront exécutées.

• Domaine - C’est ici 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 mettez pas de logique spécifique à la présentation dans vos modèles ou objets de domaine

• Ne mettez pas de logique dans vos pages et vos contrôleurs, c’est-à-dire une logique permettant de sauvegarder des objets dans la base de données, de créer des connexions à une base de données, etc., ce qui rendrait la couche de présentation fragile et difficile à tester.

• Utilisez un ORM qui vous permet de découpler votre accès à la source de données et les actions du modèle.

• Suivez le paradigme contrôleur mince - modèle fat, les contrôleurs servent à contrôler le processus d’exécution, pas plus, consultez la page http://www.littlehart.net/atthekeyboard/2007/04/27/fat-models-skinny-controllers/ et le modèle, vue et contrôleur http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model

La couche de domaine modélise les activités de votre application. Cela devrait être votre interprétation claire de ses règles, de sa dynamique de composant et de son état à tout moment.

La couche d'application s'inquiète de la définition des tâches à effectuer pour réaliser une tâche d'application donnée. Il est principalement responsable du mandat du travail de domaine nécessaire et interagit avec d'autres services (externes ou non).

Par exemple , mon application logicielle financière utilise une opération utilisateur pour modifier l'état d'une entité modèle (entité définie dans DDD [89]):

• "Le chef des opérations peut approuver une proposition financière".

Mais, en tant que processus d’application, outre les conséquences types 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 d'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 l’activité principale et ma couche de présentation consiste à interpréter les commandes de l’utilisateur et à présenter les résultats.

Remarques:

• Les affaires sont un de ces mots qui mènent souvent à de multiples interprétations de sa signification, mais vous pouvez certainement trouver beaucoup d'exemples et de discussions dans DDD;
• DDD est l'abréviation de Domain-Driven Design book par Eric Evans et le 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 application est supposée être conçue pour fournir certaines fonctions sur ce qu'une interface système (application) peut faire (par exemple, une API ou RESTful). Par exemple, les utilisateurs peuvent se connecter à un système et, dans cette action d'application (connexion), les codes de couche d'application sont les codes client de la couche de domaine (ou couche d'infrastructure), dans lesquels l'extraction de l'objet Domaine de l'utilisateur et l'application des méthodes de cet objet fonction 'login'.

La couche d'application doit également être conçue comme une couche d'isolation, 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).

Le but 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 vis-à-vis des autres couches et des préoccupations de l'application.

Cela vous permet de vous concentrer sur le domaine lui-même sans distraction (telle que la coordination entre l'interface utilisateur et les services de persistance).

• La couche d'application et la couche de domaine entrent toutes deux dans le champ d'application.
• La couche d'application agit comme une API.
• La couche de domaine agit comme une implémentation de l'API. Elle contient une logique métier et est donc également appelée couche de logique métier.

La principale raison de ces limites est la 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. En outre, l'interface utilisateur doit être responsable de la mise à jour des contrôles dans l'interface utilisateur, de la récupération des valeurs de l'entrée utilisateur et de leur traduction en un élément pouvant être utilisé par la couche de domaine, sans plus. Il doit appeler les opérations fournies par la couche de domaine pour effectuer les actions nécessaires (par exemple, enregistrer ce fichier). Un service Web appelé doit être chargé de la conversion du support de transmission en un élément que la couche de domaine peut utiliser, puis d'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 implémentée, peut vous permettre de modifier certaines parties de votre code sans en affecter les autres. Par exemple, l'ordre de tri d'une collection d'objets renvoyée doit peut-être être modifié. Comme 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 modifié. En plus de ne pas avoir à modifier la façon dont il est récupéré à partir du magasin de données, ou 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 à gérer que possible.

Il est à noter que certaines choses ne peuvent pas être classées dans une couche spécifique du domaine (par exemple, la journalisation, la validation et l'autorisation). Ces éléments sont généralement qualifiés de problèmes transversaux et peuvent, dans certains cas, être traités comme une couche autonome que toutes les autres couches peuvent voir et utiliser.

Personnellement, je pense que l'approche par couches est obsolète et que l'approche par service est meilleure. Vous avez toujours la ligne tranchée sur qui fait quoi, mais cela ne vous oblige pas à être aussi hiérarchique. Par exemple, un service de bons de commande, de facturation et d’expédition, du point de vue de l’application, tous ces services représentent votre domaine, et le report de responsabilité que je viens de décrire est toujours valable dans ce contexte, il vient d’être modifié. que votre domaine existe à plusieurs endroits, en utilisant davantage le concept de séparation des préoccupations.