Architecture Review Report¶

Status¶

Architecture Review Report

This document records findings identified during the CMonChoix Platform architecture review.

It is a review snapshot, not a normative architecture contract.

Purpose¶

La revue vérifie que la Platform respecte le niveau cible :

industriel ;
premium ;
maintenable ;
testable ;
scalable ;
durable sur 10 à 15 ans.

Aucune évolution majeure ne doit être engagée si un finding P0 ou P1 reste ouvert.

Scope¶

This report tracks architectural risks, gaps and remediation decisions.

Normative architecture rules are defined in the dedicated architecture documents, not in this report.

Niveaux de gravité¶

Niveau	Signification
P0	Bloquant critique
P1	Bloquant avant extension majeure
P2	Correction importante
P3	Amélioration

P0-001 — Product Model insuffisamment explicite¶

Constat¶

La documentation parle de Candidate, Canonical Identity, Resolver, Projection et Offer, mais le concept central Product n'est pas encore formalisé comme modèle métier autonome.

Risque¶

confusion entre produit, offre, modèle, variante et projection ;
Domain trop orienté comparateur ;
difficulté à étendre la Platform vers PIM, marketplace, MDM ou autres usages.

Décision¶

Créer un document Product Model avant toute extension majeure du Domain.

P0-002 — Truth Model non formalisé¶

Constat¶

La Platform n'a pas encore défini officiellement ce qui constitue une vérité métier.

Risque¶

décisions d'identité arbitraires ;
conflits difficiles à expliquer ;
mauvaise hiérarchie entre constructeur, marchand, Knowledge et heuristiques.

Décision¶

Créer un Truth Model et une hiérarchie Source of Truth.

P0-003 — Business Capabilities non séparées du Core Domain¶

Constat¶

Certaines notions peuvent représenter des capacités de la Platform plutôt que des invariants métier.

Risque¶

Domain trop applicatif ;
mélange entre vérité métier et capacité opérationnelle ;
difficulté à réutiliser le Core hors comparateur.

Décision¶

Définir un Business Capability Model.

P1-001 — Mélange des niveaux d'abstraction¶

Constat¶

La documentation mélange parfois Layer, Module, Service, Workflow, Runtime, Interface et Host.

Risque¶

mauvais placement des responsabilités ;
création de faux layers ;
onboarding difficile ;
dérive documentaire.

Décision¶

Créer un Platform Vocabulary avec une taxonomie officielle des types de composants.

P2-001 — Frontière Vertical Modules / Knowledge à clarifier¶

Constat¶

Les Vertical Modules sont encore parfois décrits comme porteurs de logique métier spécifique, alors que le Knowledge Layer doit porter le sens métier et le Domain le raisonnement.

Risque¶

verticales transformées en mini-Domain ;
duplication de règles ;
perte de modularité.

Décision¶

Créer Vertical Architecture pour repositionner les verticales comme packaging métier autour du Knowledge.

P2-002 — Boundary Architecture à renforcer¶

Constat¶

Boundary Architecture définit les règles, mais la matrice visuelle complète des dépendances n'est pas encore présente.

Risque¶

lecture moins immédiate lors des revues ;
ambiguïtés sur les dépendances autorisées.

Décision¶

Ajouter une matrice de dépendances complète.

P2-003 — Knowledge Ownership et Source of Truth à compléter¶

Constat¶

Knowledge Architecture ne définit pas encore suffisamment le propriétaire d'une connaissance et son origine de vérité.

Risque¶

connaissances non gouvernées ;
conflits entre sources ;
difficulté de versionnement.

Décision¶

Compléter Knowledge Architecture après Truth Model.

Architecture Gate¶

Une évolution est refusée si elle :

introduit une ambiguïté de responsabilité ;
augmente le couplage ;
contourne un contrat ;
dégrade le SEO ;
dégrade la performance ;
réduit la testabilité ;
ajoute une dépendance technique au Domain ;
ajoute une logique runtime au Knowledge ;
introduit un concept non défini dans le vocabulaire officiel.

Décision de revue¶

Avant toute nouvelle extension majeure, traiter en priorité :

Product Model ;
Truth Model ;
Business Capability Model ;
Platform Vocabulary.