Aller au contenu

Vertical Modules

Status: CURRENT

Rôle

Les Vertical Modules encapsulent la connaissance métier propre à une famille de produits.

Ils étendent les mécanismes génériques de la Platform sans modifier le Domain Core.

Domain Core générique
        ↓
Contracts
        ↓
Vertical Module
        ↓
Règles métier spécialisées

La dépendance reste unidirectionnelle : le Vertical Module dépend du Core et des Contracts ; le Core ne dépend d'aucune verticale.

Responsabilités

Un Vertical Module peut définir :

  • les attributs propres à la verticale ;
  • les extracteurs et normalisations locales ;
  • les règles de construction de candidats ;
  • les critères et preuves de conflit ;
  • les contributions au scoring ;
  • les enrichissements spécialisés ;
  • les règles de variante ;
  • les reason codes propres au domaine.

Il fournit des contributions métier aux moteurs génériques. Il ne remplace ni le Resolver, ni le Projection Builder, ni le Quality Scorer.

Frontières strictes

Un Vertical Module ne doit pas :

  • modifier le Domain Core ;
  • accéder directement au Frontend ;
  • contenir d'orchestration Runtime ;
  • écrire directement en base ;
  • charger l'ensemble des verticales par défaut ;
  • masquer un état unknown, ambiguous ou conflict ;
  • transformer une heuristique locale en règle globale sans preuve multi-verticale.

Les effets persistants passent par des Write Services explicites. Les opérations d'observation passent par des Read Services.

Chargement runtime

Le chargement des verticales est ciblé.

includes/bootstrap/verticals.php
        ↓
registry commun
        ↓
detection légère
        ↓
module sélectionné seulement si nécessaire

Les fichiers légers de détection peuvent être chargés avant sélection. Les modules complets ne doivent pas être chargés en masse dans les contextes frontend, CLI simple, admin read-only ou cron passif.

La présence du bootstrap vertical ne prouve pas que tous les modules métier sont actifs.

Modèle de contribution

Une verticale enrichit les objets génériques avec des preuves explicites.

Observation normalisée
        ↓
Détection de verticale
        ↓
Règles spécialisées
        ↓
Evidence / Candidate / Conflict signals
        ↓
Resolver et Quality génériques

Une contribution verticale doit rester :

  • déterministe ;
  • explicable ;
  • sérialisable ;
  • testable indépendamment du Runtime ;
  • compatible avec les statuts canoniques.

Statuts et incertitude

Une verticale ne doit jamais forcer une décision lorsque les preuves sont insuffisantes.

Les états canoniques restent :

  • resolved : preuve suffisante et cohérente ;
  • unknown : absence de preuve exploitable ;
  • ambiguous : plusieurs hypothèses plausibles ;
  • conflict : preuves incompatibles.

Les reason codes expliquent la décision sans dépendre du texte d'affichage.

Media Quality

Media Quality consomme des preuves issues des verticales, par exemple la couleur attendue d'une variante.

La verticale peut :

  • exposer une couleur normalisée ;
  • signaler qu'une couleur est inconnue ou ambiguë ;
  • fournir des alias et signatures métier ;
  • contribuer aux raisons de diagnostic.

Elle ne doit pas supprimer ou remplacer une image directement.

Le comportement par défaut reste audit-first et non destructif. Une mutation éventuelle doit être portée par une policy explicite et un Write Service dédié.

Industrialisation d'une verticale

Le cycle recommandé est :

Inventaire des données
        ↓
Normalisation et preuves
        ↓
Audits read-only
        ↓
Simulation
        ↓
Validation des KPI
        ↓
Activation ciblée

La validation doit inclure :

  • un jeu de données identifié ;
  • les métriques avant/après ;
  • les cas unknown, ambiguous et conflict ;
  • les régressions inter-verticales ;
  • la preuve d'absence d'effet de bord en audit ;
  • les tests unitaires et d'architecture.

Extraction vers le Core

Une règle ne rejoint le Domain Core que lorsqu'elle est réellement générique.

Une similarité entre deux verticales ne suffit pas automatiquement. L'extraction exige :

  • un besoin commun prouvé ;
  • un vocabulaire indépendant des produits concernés ;
  • un contrat stable ;
  • des tests multi-verticales ;
  • l'absence de dépendance à une taxonomie ou à un feed particulier.

Tests attendus

Chaque Vertical Module doit couvrir au minimum :

  • les cas nominaux ;
  • les données partielles ;
  • les valeurs inconnues ;
  • les ambiguïtés ;
  • les conflits bloquants ;
  • les alias marchands ;
  • le déterminisme ;
  • l'isolation par rapport aux autres verticales ;
  • l'absence d'écriture directe ;
  • le chargement ciblé du module.

Invariants

  1. Le Domain Core ne dépend d'aucune verticale.
  2. Une verticale ne remplace aucun moteur générique.
  3. Les règles locales restent confinées au module concerné.
  4. Les décisions incertaines restent explicites.
  5. Les modules complets sont chargés à la demande.
  6. Les lectures et les écritures restent séparées.
  7. Media Quality ne mute rien implicitement.
  8. Toute extraction vers le Core est justifiée par des preuves multi-verticales.

Voir aussi