Aller au contenu

Domain Core

Status: CURRENT

Le Domain Core constitue le cœur métier de CMonChoix Platform. Il porte les concepts génériques qui doivent rester stables, indépendants des marchands, du runtime WordPress, des adapters et des verticales.

Mission

Le Domain Core transforme des observations déjà normalisées en décisions métier explicables.

Il fournit notamment les concepts nécessaires pour :

  • représenter les identifiants et attributs métier ;
  • construire et comparer des candidats ;
  • résoudre une identité canonique ;
  • qualifier les conflits et ambiguïtés ;
  • produire des décisions de qualité ;
  • fournir les données nécessaires aux projections.

Le Core ne pilote aucun traitement opérationnel et n'écrit pas directement dans les tables WordPress.

Position dans l'architecture

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

La séparation entre calcul métier et persistance doit rester explicite.

Modèle de décision

Une décision métier doit pouvoir être reliée aux preuves qui l'ont produite.

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

Une décision ne doit jamais être réduite à un booléen opaque lorsqu'un état plus précis est disponible.

Les états suivants doivent notamment rester distincts :

  • matched ;
  • mismatched ;
  • unknown ;
  • ambiguous ;
  • conflict ;
  • not_applicable.

Responsabilités

Le Domain Core est responsable de :

  • la représentation des identifiants ;
  • la construction de candidats ;
  • la résolution d'identité ;
  • les politiques de conflit génériques ;
  • les scores et décisions métier génériques ;
  • les objets de résultat explicables ;
  • les règles transverses réutilisables entre verticales.

Il peut exposer des ports ou contrats utilisés par les couches applicatives et les projections.

Hors périmètre

Le Domain Core ne doit jamais :

  • télécharger ou parser un feed ;
  • lire directement $_GET, $_POST, $_REQUEST ou $_SERVER ;
  • dépendre de WordPress ou de WP-CLI ;
  • exécuter du SQL ;
  • écrire dans une projection ;
  • gérer les batches, offsets, retries ou cron ;
  • produire du HTML ou du JSON HTTP ;
  • contenir une règle propre à une verticale particulière.

Ces responsabilités appartiennent au Pipeline, aux Vertical Modules, aux adapters, au Runtime ou aux Write Services.

Vertical Modules

Les Vertical Modules complètent le Core avec des règles spécifiques à un domaine produit.

Domain Core
    ↑
Contracts / Extension points
    ↑
Vertical Module ciblé

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 documentés.

Elle ne doit pas modifier les invariants génériques du Core ni forcer le Core à dépendre d'elle.

Le chargement d'une verticale doit rester ciblé. Le Runtime ne doit pas charger tous les modules métier pour choisir une seule verticale.

Quality et Media Quality

Quality mesure et qualifie l'état des données ou d'une décision. Elle ne doit pas devenir un mécanisme implicite de correction.

Pour Media Quality, l'état courant est audit-first :

  • l'évaluation repose sur des évidences explicites ;
  • les résultats distinguent correspondance, contradiction, inconnu et ambiguïté ;
  • la mutation est désactivée par défaut ;
  • une image principale n'est jamais supprimée uniquement parce qu'une preuve est insuffisante ;
  • un remplacement exige une décision séparée et une confiance suffisante.

Le Domain Core produit la décision ; un Write Service explicitement invoqué décide ensuite s'il faut la persister.

Déterminisme

À entrées identiques et configuration identique, le Domain Core doit produire le même résultat.

Le résultat doit inclure, lorsque pertinent :

  • un statut ;
  • un score ou niveau de confiance ;
  • des reason codes ;
  • les preuves retenues ;
  • les preuves rejetées ou contradictoires ;
  • les avertissements ;
  • une version de règle ou de politique lorsque nécessaire.

Le déterminisme permet les audits, simulations, replays et comparaisons entre versions.

Dépendances autorisées

Le Domain Core peut dépendre :

  • du langage PHP ;
  • de ses propres Value Objects et services métier ;
  • de contrats stables ;
  • de bibliothèques pures sans effet de bord, lorsqu'elles sont explicitement admises.

Il ne dépend pas :

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

Les dépendances vers l'infrastructure passent par des ports.

Tests attendus

Le Core doit être testable sans WordPress, base de données ou réseau.

Les tests couvrent notamment :

  • les cas nominaux ;
  • les données manquantes ;
  • les conflits et ambiguïtés ;
  • les résultats déterministes ;
  • les reason codes ;
  • les seuils de confiance ;
  • l'absence d'effet de bord ;
  • la stabilité des contrats sérialisés.

Les tests d'architecture doivent empêcher l'introduction de dépendances vers le Runtime, WordPress ou les adapters.

Invariants

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

Voir aussi