Dans DDD, un service de domaine est-il essentiellement un modèle de façade et / ou de médiateur?

Dans Domain Driven Design, la couche de domaine peut avoir plusieurs services (traditionnels). Par exemple, pour le domaine Utilisateur, nous pouvons avoir:

Un UserFactory, qui construit des objets utilisateur de différentes manières
Un UserRepository, qui est responsable de l'interaction avec les services de persistance dans la couche infrastructure

Un service utilisateur dans la couche domaine est-il simplement un médiateur et / ou une façade pour ces deux services et la couche infrastructure, ou y a-t-il plus?

object-oriented object-oriented-design domain-driven-design

— e_i_pi
source

Voir aussi Services en DDD et Services en DDD

— Erik Eidt

J'ai beaucoup lu les articles de Level Gorodinski, mais je n'ai jamais vu ce deuxième lien. Bonne lecture, touche définitivement à certains points importants!

— e_i_pi

Réponses:

Domain services sont mieux décrits par ce qu'ils ne sont pas:

ils ne sont ni EntitiesniAggregate roots
ils ne sont pas Value objects
porter des connaissances de domaine qui ne correspondent naturellement pas à un seul Entity ou à un Value object

Un exemple de a Domain serviceest un Saga/Process manager: il coordonne un long processus impliquant plusieurs Aggregate roots, possibles de différents Bounded contexts.

Cela étant dit, ce qui est un Domain serviceet comment il est mis en œuvre sont deux choses orthogonales.

Un service utilisateur dans la couche domaine est-il simplement un médiateur et / ou une façade pour ces deux services et la couche infrastructure, ou y a-t-il plus?

Certains services de domaine comme un UserRepository(composé d'une interface définie dans le Domain layeret d'une implémentation concrète dans le Infrastructure layer) peuvent être implémentés à l'aide du Facademodèle de conception. Les autres services de domaine ne le sont pas.

Il n'y a pas de règle stricte sur la façon de les implémenter, à part la règle importante qui Domain layerne doit pas dépendre d'autres couches (et SOLID ).

— Constantin Galbenu
source

Merci, je pense que je comprends enfin la couche de domaine. En plus de contenir les objets de données (agrégats, entités et objets de valeur), il contient également les règles métier, mais pas la mise en œuvre concrète de ces règles. Les services de domaine définissent ce que vous pouvez faire pour les objets de données de domaine, mais ne savent pas comment ces opérations fonctionnent en interne.

— e_i_pi

Les règles métier @e_i_pi ne sont protégées que par les agrégats et leurs entités imbriquées. Les services de domaine n'y participent pas.

— Constantin Galbenu

@e_i_pi où l'opération implique plusieurs agrégats. Par exemple, étant donné la liste des comptes bancaires (agrégats) d'une personne (un autre agrégat), un service de domaine calculerait le solde total de ces comptes.

— Constantin Galbenu

@e_i_pi: Je pense que vous avez quelques idées fausses. Ainsi, l'ensemble de la couche de domaine est un modèle logiciel de votre domaine. Vous avez dit - "En plus de contenir les objets de données (agrégats, entités et objets de valeur)" - ce ne sont pas des "objets de données" dans le sens où ils ne contiennent que des données; ceux-ci implémentent en fait des règles de domaine, ils définissent le comportement. Maintenant, les services de domaine , selon le livre DDD d'E. Evans , sont les aspects du domaine qui ne s'intègrent pas naturellement dans un objet (une entité ou un objet de valeur).

— Filip Milovanović

Un service de domaine "est plutôt défini uniquement en termes de ce qu'il peut faire pour un client", défini en termes d'autres éléments du modèle de domaine (il orchestre donc ces éléments d'une manière ou d'une autre et applique les règles de domaine qui régissent cette orchestration). Le service de domaine lui-même est sans état. Il y a aussi le concept des services d'application , qui résident dans une couche de niveau supérieur et implémentent essentiellement des user stories, ou des cas d'utilisation équivalents, en agissant comme une interface vers la couche de domaine. Notez que le rapport des objets par rapport aux services variera selon le domaine en cours de modélisation.

— Filip Milovanović

Je vois des services dans DDD suite à l' inversion de dépendance .

Si vous deviez utiliser des dépendances "simples", votre code de domaine appellerait la base de données pour enregistrer ou interroger une entité, ou une fabrique, qui crée une entité, qui est liée à la base de données ou à un service externe ou à une sorte d'autre code d'infrastructure.

Mais ce n'est pas ainsi que le code de domaine devrait être. Le code de domaine ne doit pas dépendre du code d'infrastructure. Comme cette dépendance rend plus difficile à tester et, éventuellement, à réutiliser. C'est pourquoi vous inversez cette dépendance. Vous faites dépendre le code d'infrastructure du code de domaine. Et pour ce faire, vous devez introduire une abstraction. Une abstraction qui définit le comportement que le code de domaine attend d'être mis en œuvre par l'infrastructure.

Et les services en DDD sont cette abstraction. Dans la majorité des cas, pour le code de domaine, ces services doivent être des interfaces simples. Et l'implémentation devrait être dans le code d'infrastructure, qui dépend de ces interfaces.

— Euphorique
source

Merci pour votre réponse, les deux réponses ensemble m'ont donné le "aha!" moment. Je pense que sans votre réponse, je n'aurais pas entièrement saisi le concept, mais je préfère la réponse de Constantine comme indicateur aux futurs lecteurs.

— e_i_pi