web-dev-qa-db-fra.com

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

Dans la conception pilotée par domaine, 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 UserService 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-orientedobject-oriented-designdomain-driven-design
13
e_i_pi

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

  • ils ne sont ni Entities ni Aggregate roots
  • ils ne sont pas Value objects
  • transporter des connaissances de domaine qui ne correspondent pas naturellement à une seule Entity ou une Value object

Un exemple de Domain service est un Saga/Process manager: il coordonne un long processus impliquant plusieurs Aggregate roots, possible à partir de différents Bounded contexts.

Cela étant dit, ce qui est un Domain service et comment il est implémenté 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 layer et une implémentation concrète dans le Infrastructure layer) peut être implémenté en utilisant le modèle de conception Facade. Les autres services de domaine ne le sont pas.

Il n'y a pas de règle stricte sur comment les implémenter, autre que la règle importante que le Domain layer ne doit pas dépendre d'autres couches (et S.O.L.I.D. ).

11
Constantin Galbenu

Je vois des services dans DDD à la suite de 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.

1
Euphoric