Services métier du Product Domain¶

Statut¶

Spécification métier normative.

Qu'est-ce qu'un Domain Service ?¶

Un Domain Service contient une opération métier qui ne trouve pas naturellement sa place dans une seule Entity ou un seul Value Object.

Il sert donc à coordonner une règle métier transversale tout en restant indépendant de WordPress, SQL, des feeds et du Runtime.

Règle centrale¶

Un Domain Service applique de la logique métier. Il ne doit pas devenir un service technique.

Entrées métier
      ↓
Domain Service
      ↓
Décision métier explicite

La persistance éventuelle est traitée ensuite par les frontières prévues à cet effet.

Services principaux¶

`ProductIdentityResolutionService`¶

Il résout l'identité canonique à partir de plusieurs preuves.

Il doit conserver les cas d'incertitude et de conflit au lieu de forcer une réponse.

`ProductConsistencyService`¶

Il évalue l'état de cohérence d'un Product à partir de son identité, de ses identifiants, observations, variantes et conflits.

`ProductMergeService`¶

Il permet de fusionner deux Products lorsque leur équivalence est réellement démontrée.

Une fusion est une opération sensible : elle ne doit pas reposer sur un simple titre similaire ou sur une seule preuve faible.

`ProductSplitService`¶

Il permet de séparer un Product lorsqu'on découvre qu'il regroupe en réalité plusieurs identités distinctes.

`ProductConflictResolutionService`¶

Il traite la résolution explicite des conflits du Product Domain.

Exemple concret¶

Si deux fiches marchands semblent représenter le même smartphone :

les observations et identifiants deviennent des preuves ;
le service de résolution analyse ces preuves ;
il peut produire une identité résolue, inconnue, ambiguë ou conflictuelle ;
une éventuelle fusion n'est envisagée qu'après une décision métier suffisamment fiable.

Le Domain Service ne doit pas écrire directement dans une table SQL pour « faire marcher » le résultat.

Règles¶

Les Domain Services doivent :

respecter les invariants ;
rester déterministes lorsque c'est possible ;
être testables sans base de données ;
ne pas dépendre de WordPress ;
ne pas dépendre d'un feed particulier ;
ne pas contenir de code de transport ou d'interface.

Quand utiliser un Domain Service ?¶

Utilise cette notion lorsqu'une opération :

est réellement métier ;
implique plusieurs objets ou règles du domaine ;
n'appartient clairement à aucune Entity unique.

N'utilise pas un Domain Service simplement pour déplacer du code technique hors d'une classe devenue trop grande.

Pour diagnostiquer un comportement incorrect¶

Si une fusion, une séparation ou une résolution paraît fausse :

vérifier les preuves entrantes ;
vérifier les invariants et Policies ;
vérifier le Domain Service responsable ;
vérifier le résultat avant persistance ;
seulement ensuite examiner les écritures ou projections.

Décision¶

Les Domain Services encapsulent uniquement les opérations métier transversales du Product Domain.