Présentation des Vertical Modules¶

Vue d'ensemble¶

Les Vertical Modules encapsulent l'ensemble des règles métier propres à une famille de produits.

Ils constituent le point d'extension naturel de la Platform.

Leur rôle est d'enrichir le comportement générique du Domain Core sans jamais le modifier.

Cette séparation permet d'ajouter de nouvelles verticales tout en conservant un cœur fonctionnel stable, réutilisable et indépendant des métiers.

Pourquoi des Vertical Modules ?¶

Tous les produits ne suivent pas les mêmes règles.

Par exemple :

Un smartphone possède :

une capacité de stockage ;
une couleur ;
une mémoire vive ;
une connectivité réseau.

À l'inverse, une imprimante possède :

une technologie d'impression ;
un format papier ;
une compatibilité avec certaines cartouches ;
une impression couleur ou monochrome.

Ces différences relèvent du métier.

Elles ne doivent jamais être intégrées au Domain Core.

Les Vertical Modules existent précisément pour isoler cette connaissance métier.

Position dans l'architecture¶

Les Vertical Modules s'appuient sur les composants génériques du Domain Core.

                Domain Core
                     │
                     ▼
             Vertical Module
                     │
                     ▼
        Règles métier spécialisées
                     │
                     ▼
                Projection

Le Domain Core ne connaît jamais les Vertical Modules.

La dépendance est toujours orientée dans un seul sens.

Responsabilités¶

Chaque Vertical Module est responsable de son propre domaine métier.

Il peut notamment définir :

les attributs spécifiques ;
les règles de normalisation locales ;
les heuristiques métier ;
les règles de résolution complémentaires ;
les stratégies de scoring propres à la verticale ;
les conflits spécifiques au domaine concerné.

Toutes ces règles restent confinées dans le module.

Ce qui appartient à une verticale¶

Relèvent d'un Vertical Module :

la définition des attributs métier ;
les variantes d'un produit ;
les règles propres à une famille de produits ;
les enrichissements spécifiques ;
les exceptions métier.

En revanche, les concepts génériques restent dans le Domain Core.

Ce qui ne doit jamais appartenir à une verticale¶

Un Vertical Module ne doit jamais :

modifier le Domain Core ;
remplacer le Resolver ;
contenir des composants Frontend ;
gérer les projections globales ;
accéder directement aux interfaces utilisateur.

Il complète la Platform.

Il ne la pilote pas.

Cycle d'industrialisation¶

Une nouvelle verticale suit toujours le même processus.

Création
     │
     ▼
Read Services
     │
     ▼
Audits
     │
     ▼
Simulations
     │
     ▼
Validation
     │
     ▼
Intégration

Cette méthode garantit que chaque verticale est validée avant son intégration dans le fonctionnement normal de la Platform.

Les verticales de CMonChoix¶

Au moment de la rédaction de cette documentation, plusieurs verticales ont déjà permis de valider les principes de l'architecture.

La verticale Smartphone constitue la première preuve de concept complète de l'approche Identifier First.

Elle a démontré que le Domain Core pouvait résoudre efficacement des produits complexes sans contenir de logique spécifique aux smartphones.

La verticale Photo a confirmé cette architecture.

Les difficultés rencontrées relevaient principalement de règles métier propres au domaine photographique et non d'une faiblesse du Domain Core.

D'autres verticales sont prévues afin d'étendre progressivement la couverture fonctionnelle de la Platform, notamment les téléviseurs, le gaming, les imprimantes, la mobilité, les jouets et le bien-être.

Ajouter une nouvelle verticale¶

L'ajout d'une nouvelle verticale ne nécessite pas de modifier le Domain Core.

Il consiste à :

créer un nouveau Vertical Module ;
définir les attributs métier ;
développer les Read Services associés ;
réaliser les audits ;
mesurer les KPI ;
valider le comportement obtenu.

Cette approche permet une évolution incrémentale de la Platform.

Invariants¶

Tous les Vertical Modules respectent les principes suivants.

Isolation¶

Chaque verticale est autonome.

Elle ne dépend pas des autres verticales.

Réutilisation¶

Chaque verticale réutilise les composants génériques du Domain Core.

Elle ne les duplique jamais.

Responsabilité unique¶

Une règle métier appartient toujours à une seule verticale.

Les règles communes sont progressivement extraites vers le Domain Core lorsqu'elles deviennent réutilisables.

Évolutivité¶

Une verticale peut évoluer indépendamment des autres tant qu'elle respecte les contrats définis par la Platform.

Cette propriété facilite le développement parallèle de plusieurs domaines métier.