Objets/services de domaine et couche de logique métier
Que sont les objets de domaine et les services de domaine dans l'architecture logicielle? Je ne les connais pas ou en quoi elles diffèrent de la couche de logique métier?
Différentes personnes utilisent ces termes de manière légèrement différente, mais voici ce que je pense:
1) "Business" et "domaine" sont à peu près synonymes. "Domaine" est un peu plus général en ce sens qu'il ne présume pas que vous écrivez une application métier. Donc, si nous écrivions une application scientifique ou un jeu, nous pourrions préférer nous référer à la partie pertinente du code en tant que code "domaine" plutôt que code "professionnel". Donc, dans la suite de cette explication, je vais utiliser "domaine" car c'est plus général.
2) la "logique de domaine" comprend à la fois les "objets de domaine" et les "services de domaine". Pour diverses raisons (techniques ou autres), de nombreuses architectures utilisent une conception dans laquelle la logique de domaine est divisée en objets permettant de stocker des données ("objets de domaine") et des objets manipulant ceux-ci ("services de domaine"). Martin Fowler et d’autres ont fait remarquer que ce n’était pas très OO puisqu’une grande partie du concept OO consiste à associer fonctionnalité et données, et c’est vrai, mais c’est ce qu’il est . Les objets de domaine sont les données et les services de domaine sont la partie "faire-avec-les-données".
3) Dans la conception par domaine, l’idée est de revenir à la vraie conception OO, afin que les différentes méthodes de service renvoient aux objets de domaine afin que vous ayez des objets au sens OO. plutôt que ce qu'on appelle parfois des objets "anémiques". Dans un DDD, les objets de domaine eux-mêmes sont plus robustes et forment donc la logique de domaine. En réalité, certains services de domaine peuvent également exister, mais ils sont généralement plus petits dans un modèle DDD que dans un modèle plus classique d'objet de domaine par rapport à un modèle de services.
La couche de logique applicative est également appelée couche de domaine. C'est la couche/le niveau qui gère toute la logique métier.
Les objets de domaine et les services de domaine sont des classes que vous utilisez pour créer votre couche de domaine.
Nous devons comprendre les responsabilités de la couche application et de la couche domaine (métier) pour pouvoir saisir la différence ..___ La couche domaine représente les objets métier, principalement des entités de l'entreprise, éventuellement abstraites dans une certaine mesure, et services de domaine. La couche de domaine ne change que lorsque l'entreprise change ou que le contexte du domaine change au sein de l'entreprise . La couche d'application "vit" au-dessus de la couche de domaine et est souvent (de préférence) séparée de la couche de domaine, comme avec un asp.net MVC Web Application où la partie contrôleur est la couche d'application et la partie HTML est la couche de présentation. La couche d'application change pour s'adapter à l'objectif de cette application spécifique (ou service, API, application, etc.)
Permettez-moi de vous donner cet exemple de scénario d'application d'entreprise avec lequel j'ai travaillé, afin d'expliquer pourquoi un niveau de domaine et un niveau d'entreprise contiennent tous deux une logique métier mais sont différents.
Supposons que j'ai un produit COTS qui est un pur moteur de gestion de cas, par exemple une implémentation OMG CMMN. Une multitude de logique métier dans un niveau métier qui fonctionne avec un ensemble d’entités du niveau données.
Continuez maintenant à supposer que j'ai deux clients intégrateurs de systèmes, l'un construit un système de gestion des cas juridiques et l'autre qui souhaite la gestion de cas en soins de santé. les deux sont de la gestion de cas, mais ont leurs propres termes, objets, procédures, architectures industrielles, etc.
Chacun ajoutera son propre niveau de domaine, afin de pouvoir travailler dans les termes et les concepts du domaine métier correspondant.
Donc, oui, il contient une logique métier, mais un niveau de domaine est un moyen d'encapsuler une activité générique réutilisable avec une activité spécifique.
Plus l'application est "simple", plus le modèle de domaine et le modèle de données sont similaires, ainsi que la logique métier et la logique de domaine. Mais lorsque vous augmentez l'utilité d'un composant divergent, les problèmes sont finalement séparés.