Domain Core — le cœur métier générique¶

Status: CURRENT

Le Domain Core est le cœur métier de CMonChoix. Il contient les mécanismes génériques qui permettent de comprendre et décider, sans dépendre d’un marchand, de WordPress, d’une base SQL ou de l’interface du site.

À quoi sert le Domain Core ?¶

Le Domain Core transforme des données déjà préparées en décisions métier explicables.

Il intervient après les étapes techniques d’ingestion et de normalisation.

Exemple simple :

Titre marchand brut
    ↓
Normalisation
    ↓
Marque / modèle / capacité / indices disponibles
    ↓
Domain Core
    ↓
Décision : identité résolue, inconnue, ambiguë ou en conflit

Le Domain Core ne télécharge pas le feed et n’affiche pas la fiche produit. Il travaille au milieu de la chaîne, là où il faut transformer des preuves en décision métier.

Pourquoi il doit rester générique¶

Si le cœur métier commence à contenir des exceptions pour Samsung, Acer, les smartphones ou les appareils photo, il devient progressivement impossible à réutiliser et à comprendre.

La règle est donc :

ce qui est générique appartient au Domain Core ;
ce qui est propre à une famille de produits appartient à un Vertical Module ;
ce qui est propre à un marchand ou un feed appartient aux couches de normalisation prévues ;
ce qui concerne WordPress, SQL ou Docker appartient aux couches techniques.

Exemple¶

Le concept de « candidat possible pour une identité » est générique : il peut appartenir au Domain Core.

La règle disant comment interpréter 256 Go pour une variante de smartphone est spécialisée : elle appartient à la verticale Smartphone.

Où se situe-t-il dans CMonChoix ?¶

Feeds marchands
      ↓
Pipeline technique
      ↓
Observations normalisées
      ↓
Domain Core
      ↓
Décisions métier
      ↓
Projection / Write Services
      ↓
Read models / Frontend

Deux séparations sont particulièrement importantes :

le Domain Core ne lit pas directement les données brutes des marchands ;
le Domain Core ne persiste pas directement ses décisions.

Il calcule. D’autres couches orchestrent, écrivent et affichent.

Ce qu’il manipule¶

Le Domain Core fournit notamment les concepts nécessaires pour :

représenter les identifiants métier ;
construire des candidats ;
comparer les preuves ;
résoudre une identité canonique ;
représenter les conflits et ambiguïtés ;
produire des scores ou niveaux de confiance génériques ;
produire des objets de résultat explicables ;
alimenter les projections avec des décisions déjà établies.

De la preuve à la décision¶

Le modèle général est :

Observation
    ↓
Normalisation
    ↓
Evidence
    ↓
Candidate
    ↓
Resolver / Scorer
    ↓
Decision
    ↓
Projection éventuelle

Evidence¶

Une evidence est une preuve ou un signal exploitable : marque normalisée, référence, identifiant, attribut technique, etc.

Candidate¶

Un Candidate est une possibilité que le moteur doit évaluer.

Resolver¶

Le Resolver détermine, lorsque les preuves le permettent, quel candidat doit être retenu.

Scorer¶

Un Scorer attribue un score ou niveau de confiance selon un contrat défini. Un score aide à décider ; il ne remplace pas la logique complète de résolution ou les règles de conflit.

Pourquoi un simple vrai/faux ne suffit pas¶

Une décision métier sérieuse doit conserver la nuance.

Selon le mécanisme concerné, on peut rencontrer des états tels que :

matched : correspondance établie ;
mismatched : contradiction établie ;
unknown : preuves insuffisantes ;
ambiguous : plusieurs interprétations restent possibles ;
conflict : des preuves sont incompatibles ;
not_applicable : la règle ne s’applique pas au cas.

unknown ne signifie donc pas mismatched.

Cette distinction évite de transformer un manque d’information en conclusion négative.

Ce dont le Domain Core est responsable¶

Il possède :

la représentation générique des identifiants ;
la construction générique des candidats ;
les mécanismes de résolution d’identité ;
les politiques de conflit génériques ;
les décisions et scores métier génériques ;
les objets de résultat et leurs raisons ;
les règles réellement transverses entre plusieurs verticales.

Il peut exposer des ports ou contrats utilisés par les autres couches.

Un port est une interface abstraite qui dit ce dont le Domain a besoin sans imposer l’implémentation technique utilisée pour le fournir.

Ce qu’il ne doit jamais faire¶

Le Domain Core ne doit pas :

télécharger ou parser un feed marchand ;
lire $_GET, $_POST, $_REQUEST ou $_SERVER ;
dépendre de WordPress ou WP-CLI ;
exécuter une requête SQL de persistance ;
écrire directement une projection ;
gérer des batchs, offsets, retries ou cron ;
produire du HTML ou une réponse HTTP ;
contenir une règle propre à une verticale précise ;
décider du moment où une tâche doit être lancée.

Ces responsabilités appartiennent au Pipeline, aux Vertical Modules, aux Adapters, au Runtime, à l’Infrastructure ou aux Write Services.

Relation avec les Vertical Modules¶

Les Vertical Modules enrichissent le cœur avec les connaissances propres à une famille de produits.

Vertical Module ciblé
        ↓
Contracts / extension points
        ↓
Domain Core

Une verticale peut fournir :

des extracteurs d’attributs ;
des règles de comparaison ;
des critères de scoring ;
des reason codes spécifiques ;
des seuils métier documentés.

Elle ne doit jamais modifier les invariants génériques du cœur ni obliger le Domain Core à dépendre d’elle.

Pourquoi ne pas charger toutes les verticales ?¶

Si un traitement concerne un smartphone, charger toutes les connaissances Photo, TV, Gaming, etc. ajoute du couplage et rend le comportement plus difficile à contrôler.

Le chargement doit rester ciblé sur la verticale utile.

Quality et Media Quality¶

La qualité sert à évaluer l’état d’une donnée ou d’une décision.

Elle ne doit pas devenir une correction automatique cachée.

Pour Media Quality, le principe est audit-first :

analyser les preuves ;
distinguer correspondance, contradiction, inconnu et ambiguïté ;
ne rien modifier par défaut ;
ne jamais supprimer une image parce que les preuves sont simplement insuffisantes ;
séparer la décision de qualité de l’éventuelle écriture corrective.

Le Domain Core ou le moteur de qualité produit le constat. Un Write Service explicitement invoqué porte ensuite la mutation si elle a été validée.

Déterminisme¶

Le Domain Core doit être déterministe : mêmes entrées + même configuration + mêmes règles = même résultat.

Un résultat important devrait exposer, lorsque pertinent :

un statut ;
un score ou niveau de confiance ;
des reason codes ;
les preuves retenues ;
les preuves contradictoires ;
les avertissements ;
la version des règles utilisées.

Cela permet de rejouer un cas, comparer deux versions du moteur et comprendre une régression.

Dépendances autorisées¶

Le Domain Core peut dépendre :

du langage PHP ;
de ses propres Value Objects ;
de ses services métier purs ;
de contrats stables ;
de bibliothèques pures explicitement admises.

Un Value Object est un objet représentant une valeur métier par son contenu plutôt que par une identité technique, par exemple un identifiant normalisé ou une référence structurée.

Il ne doit pas dépendre directement :

du plugin WordPress ;
du Runtime ;
du Frontend ;
des Adapters HTTP, Admin ou CLI ;
d’une implémentation SQL ;
d’une verticale concrète.

Comment tester le Domain Core¶

Le cœur doit pouvoir être testé sans WordPress, sans base de données et sans réseau.

Les tests doivent couvrir :

les cas normaux ;
les données manquantes ;
les ambiguïtés ;
les conflits ;
le déterminisme ;
les reason codes ;
les seuils de confiance ;
l’absence d’effets de bord ;
la stabilité des contrats sérialisés.

Des tests d’architecture doivent également empêcher l’introduction accidentelle de dépendances vers WordPress, le Runtime ou les Adapters.

Signaux d’alerte lors d’une modification¶

Une modification est suspecte si elle introduit dans le Domain Core :

un appel WordPress ;
une requête SQL ;
un nom de marchand ;
une règle exclusivement Smartphone, Photo ou Gaming ;
un traitement de cron ;
un rendu HTML ;
une écriture en base ;
une dépendance vers un fichier frontend.

Cela signifie généralement que la responsabilité est placée dans la mauvaise couche.

Procédure pour diagnostiquer une mauvaise décision métier¶

Si CMonChoix prend une mauvaise décision :

récupérer les observations normalisées utilisées ;
vérifier les preuves produites ;
vérifier les candidats générés ;
regarder les reason codes et conflits ;
identifier si la règle fautive est générique ou verticale ;
reproduire le cas dans un test ou une simulation ;
corriger la couche responsable ;
vérifier que les autres verticales ne régressent pas ;
seulement ensuite reconstruire ou réécrire les données dérivées si nécessaire.

Ne pas commencer par corriger manuellement une valeur dans la projection : cela masquerait la vraie cause.

Invariants à retenir¶

Le Domain Core reste indépendant de WordPress et de la persistance.
Une règle spécifique reste confinée dans son Vertical Module.
Une décision métier reste explicable par ses preuves et reason codes.
unknown n’est pas assimilé à mismatched.
Le scoring ne remplace ni la résolution ni une politique de mutation.
Aucun calcul du Core ne déclenche une écriture persistante.
À entrées et configuration identiques, le résultat est reproductible.
Media Quality reste non destructif par défaut.

Pour la personne qui reprend le projet¶

Retenez cette image mentale :

Le Pipeline prépare les faits. Le Domain Core raisonne sur ces faits. Les Write Services enregistrent les décisions. Le Frontend les affiche.

Si vous trouvez du SQL, du WordPress ou une règle propre à un marchand dans le cœur métier, il faut vérifier sérieusement si cette responsabilité n’a pas dérivé vers la mauvaise couche.