Patterns d'architecture
Intention
Cette section décrit les patterns d'architecture qui structurent la plateforme FLOW.
Un pattern n'est pas une technologie.
C'est une manière récurrente d'organiser les responsabilités, les informations, les décisions métier et les interactions entre composants.
Les patterns d'architecture donnent le vocabulaire commun.
Les fiches produits expliquent comment ce vocabulaire s'applique concrètement dans FLOW.
Pourquoi cette section ?
Les fiches produits FLOW mobilisent plusieurs patterns transverses : Case Management, Event-Driven Architecture, Self-contained System, CQRS, projection locale de décision, Operational DataHub, Event Sourcing, externalisation des décisions métier, API conversationnelle, plateforme ouverte et gouvernée.
Sans section dédiée, ces patterns seraient dispersés dans les fiches produit.
Cette section sert donc à :
- expliciter les patterns avant de les appliquer ;
- éviter que chaque fiche produit redéfinisse les mêmes concepts ;
- donner une base de discussion commune entre architecture, PO, PM, IT et métiers ;
- distinguer les choix d'architecture des choix technologiques ;
- relier les patterns aux produits FLOW.
Patterns disponibles
| Pattern | Rôle dans FLOW | Produits principalement concernés |
|---|---|---|
| Case-centric orchestration | Faire émerger le processus à partir de la demande, des faits et des décisions. | Socle Case Management |
| Event-Driven Architecture | Faire circuler les faits opérationnels entre systèmes sans dépendre de flux projet point à point. | Case Management, Stock Unifié, données en transit |
| API conversationnelle | Maintenir un dialogue corrélé, asynchrone et observable entre domaines, Cases et systèmes contributeurs. | Case Management, Stock Unifié, Supply Service Registry |
| Self-contained System (SCS) | Concevoir les produits critiques comme des unités autonomes de responsabilité, capables de tenir leurs cas d'usage principaux sans dépendances synchrones cachées. | Case Management, Stock Unifié, Product Agreement Catalog, Fulfillment Network |
| CQRS et projections | Séparer actions, événements, modèles de lecture et projections métier. | Stock Unifié, Vues 360, Case Management |
| Projection locale de décision | Donner au moteur de décision les projections dont il a besoin localement, sans dépendre d'appels synchrones à des APIs externes. | Case Management, Stock Unifié, Product Agreement Catalog, Fulfillment Network |
| Sources de référence, projections et vues | Cartographier où une information est contrôlée par un processus, et distinguer source de référence, projection, vue et agrégat. | Case Management, Vues 360, Product Agreement Catalog, données en transit |
| Operational DataHub | Construire une vérité opérationnelle fraîche, gouvernée et consommable. | Stock Unifié, Vues 360, données en transit |
| Event Sourcing / Ledger | Historiser les événements ou mouvements pour reconstruire, auditer et expliquer. | Stock Unifié, Case Management |
| Externalisation des décisions métier | Sortir règles, policies et variations métier des processus figés. | Case Management, Product Agreement Catalog, Stock Unifié |
| Rôles, relations et policies | Éviter de figer dans le cœur des cardinalités qui relèvent de règles métier variables. | Product Agreement Catalog, Supply Service Registry, Vues 360 |
| Plateforme ouverte et gouvernée | Permettre à des domaines externes de configurer, développer et consommer sans recréer des silos. | Plateforme FLOW, tous produits |
À retenir
Les patterns ne sont pas des dogmes.
Ils servent à sécuriser les choix structurants de FLOW : où placer la vérité, où placer la décision métier, où placer la lecture, où placer l'exécution, et comment éviter que la convergence ne recrée un grand monolithe.