Knowledge Architecture¶
Statut¶
Document d'architecture cible.
Ce document définit le rôle du Knowledge Layer dans CMonChoix Platform V2.
Il ne décrit pas une implémentation technique.
Mission¶
Le Knowledge Layer contient la connaissance métier utilisée par la Platform.
Le Domain possède le raisonnement.
Le Knowledge possède le sens.
Domain = comment raisonner.
Knowledge = sur quoi raisonner.
Cette séparation permet au Domain de rester stable pendant que les métiers, verticales, taxonomies, vocabulaires et règles d'interprétation évoluent.
Définition¶
Une connaissance métier est une information structurée qui permet d'interpréter un produit, une offre ou un attribut dans un contexte fonctionnel.
Une connaissance peut être :
- un vocabulaire ;
- une taxonomie ;
- un dictionnaire ;
- une synonymie ;
- une règle de normalisation ;
- une classification ;
- une compatibilité ;
- une exception documentée ;
- une politique métier.
Une connaissance décrit le métier.
Elle ne doit pas devenir une orchestration technique.
Domain vs Knowledge¶
| Domain | Knowledge |
|---|---|
| Raisonnement générique | Sens métier |
| Concepts universels | Vocabulaires métier |
| Algorithmes purs | Taxonomies |
| Candidate | Marques |
| Identifier | Familles produit |
| Resolver | Synonymes |
| Projection | Attributs verticaux |
| Conflict Policy | Compatibilités |
| Quality | Exceptions métier |
Le Domain ne doit jamais contenir une règle comme : si Apple alors...
Il doit manipuler uniquement des concepts génériques.
Le Knowledge fournit les valeurs, vocabulaires et interprétations nécessaires.
Invariants¶
Une connaissance métier doit être :
- déclarative ;
- versionnable ;
- documentée ;
- testable ;
- déterministe ;
- indépendante du stockage ;
- indépendante du runtime ;
- indépendante du frontend ;
- indépendante du pipeline ;
- indépendante de WordPress.
Une connaissance ne doit pas avoir d'effet de bord.
Interdits¶
Le Knowledge Layer ne doit jamais contenir :
- SQL ;
- accès WordPress ;
- hooks WordPress ;
- HTML ;
- CSS ;
- appels HTTP ;
- commandes CLI ;
- cron ;
- Docker ;
- orchestration runtime ;
- persistance ;
- cache technique ;
- logique frontend ;
- logique de synchronisation feed.
Organisation cible¶
platform/ contracts/ domain/ knowledge/ shared/ verticals/ smartphone/ printer/ camera/ gaming/ tv/ mobility/ toys/ wellness/ application/ infrastructure/ adapters/ apps/
Le Domain ne dépend pas des verticales.
Les verticales enrichissent le Knowledge.
Le Knowledge est consommé via des contrats explicites.
Shared Knowledge¶
Certaines connaissances sont communes à plusieurs verticales.
Elles ne doivent pas être recopiées.
Exemples :
- Brand ;
- Color ;
- Storage ;
- Connectivity ;
- Dimensions ;
- Material ;
- Energy ;
- Battery ;
- Warranty ;
- Packaging ;
- Condition ;
- Manufacturer.
Ces connaissances appartiennent à knowledge/shared/.
Une verticale peut les réutiliser, mais ne doit pas les redéfinir sans justification documentée.
Vertical Knowledge Modules¶
Une verticale est un module de connaissance autonome.
Elle peut définir :
- vocabulaire ;
- taxonomie ;
- familles ;
- attributs ;
- règles de normalisation ;
- compatibilités ;
- exceptions ;
- policies verticales ;
- exemples de validation.
Elle ne doit pas définir :
- un Resolver alternatif ;
- un moteur d'identité alternatif ;
- un Projection Builder alternatif ;
- une orchestration pipeline ;
- une logique frontend ;
- une dépendance SQL ou WordPress.
Extension d'une nouvelle verticale¶
Ajouter une verticale ne doit jamais modifier le Domain.
Nouvelle verticale ↓ Nouveau module Knowledge ↓ Contrats respectés ↓ Tests de connaissance ↓ Documentation ↓ Activation progressive
Le Domain reste fermé à la modification.
Le Knowledge reste ouvert à l'extension.
Cycle de vie¶
Une connaissance métier suit un cycle gouverné :
Besoin métier ↓ Spécification ↓ Documentation ↓ Validation ↓ Versionnement ↓ Publication ↓ Évolution ↓ Dépréciation
Une connaissance non documentée n'est pas une connaissance officielle.
Vision long terme¶
Le Knowledge Layer doit permettre :
- d'ajouter des verticales sans modifier le Domain ;
- de mutualiser les concepts communs ;
- de versionner les connaissances métier ;
- de remplacer une implémentation sans perdre la connaissance ;
- de faire évoluer la Platform pendant 10 à 15 ans ;
- de conserver la connaissance utile du legacy sans copier sa structure.
Principe associé :
KEEP KNOWLEDGE.
REWRITE STRUCTURE.
Voir aussi¶
- Domain Core
- Vertical Modules
- Contracts
- Identity Engine
- Industrial Quality Gates
- Architecture Atlas