Bounded Context et limites de domaine

Bounded Context (BC) est une frontière claire à l'intérieur de laquelle opère une langue unique Ubiquitous, des modèles cohérents et des invariants. À l'intérieur de la frontière, les termes sont sans ambiguïté (« Pari », « Client », « Limite »), et le contexte extérieur communique avec les contrats (événements/équipes) et ne tire pas vers l'intérieur les « queues » de sens des autres. Les frontières bien choisies réduisent la connectivité, simplifient l'échelle et accélèrent l'évolution du produit.

1) Pourquoi les frontières sont nécessaires

Réduction de la charge cognitive. L'équipe travaille avec un modèle et une langue, pas avec « toutes les entreprises à la fois ».
Isolement des invariants. Les règles critiques (équilibre ≥ 0, unicité du login) vivent au même endroit et sont protégées par des agrégats.
Gestion des changements. L'évolution du régime/règlement au sein de la Colombie-Britannique ne brise pas le voisin - il y a des contrats explicites.
Performances et fiabilité. Au sein de BC, vous pouvez choisir le modèle de cohérence et le stockage appropriés ; dehors - projections asynchrones.

2) Comment identifier Bounded Context

1. Event Storming : inscrivez les événements de domaine « ce qui s'est passé », puis les commandes « ce qu'il faut faire », puis les agrégats « qui garantit la règle ».

2. Clusters de langue : où les mots et les règles correspondent de façon stable - BC potentiel. Où le mot « Client » signifie différent (payeur vs joueur) - il y a des contextes clairement différents.

3. Invariants et surpoids : qu'est-ce qu'on ne peut pas violer et qui répond ? L'invariant → à l'intérieur du BC qui peut le garantir.

4. Flux de valeur : Regrouper les étapes qui changent souvent ensemble - ce sont les candidats à un BC.

5. Structure d'orgue : si une seule partie est faite par une équipe distincte avec des KPI distincts - c'est probablement un BC distinct (mais pas l'inverse : l'organisation ne devrait pas dicter aveuglément le modèle).

• Débat sur les termes (« pari », « ticket », « round » - différents sens).
• L'invariant le plus chaud « passe » par les services.
• Différents SLO et le rythme du changement.
• « Dual-write » entre les modules pour l'atomicité.

3) Contextes typiques (exemple de domaine d'étude)

Identity/KYC - enregistrement, niveaux de vérification, statuts de restriction.
Wallet/Ledger - bilans, virements, réserves, devises.
Betting/Orders - réception, devis, calcul.
Jeu/Round - cycle de vie du cycle, résultats.
Bonus/Promo - charges, vader, conversion.
Paiements - dépôts/retraits, statuts de passerelles de paiement.
Conformité/Reporting - rapports, audits, vitrines réglementaires.
Catalogue/Fournisseur Integration - jeux, versions, statuts des fournisseurs.
Analytics/Read Models - projections et représentations matérialisées.

4) Carte de contexte : comment les BC interagissent

• Customer–Supplier. Un fournisseur (BC) fournit des événements/données, un autre (Customer) adapte ses modèles.
• Conformist. Le client accepte le langage et le modèle Supplier tel quel (par exemple, le registre réglementaire).
• Partnership. Deux BC évoluent de façon synchrone le langage et les contrats (souvent une équipe/roadmap).
• Shared Kernel. L'ensemble de la bibliothèque/bibliothèque minimale est réalisé conjointement ; utiliser avec soin.
• Anti-Corruption Layer (ACL). Couche de protection qui traduit les modèles des autres dans leur propre langage.
• Open Host Service / Published Language. Protocoles/schémas publics, versionables et documentés.

Pratique : par défaut, utiliser l'ACL et les événements asynchrones ; Conformist - seulement si le fournisseur dicte la norme, Shared Kernel - au minimum et consciemment.

5) Bordure = langage + modèle + invariants + stockage

• Ubiquitous Language. Dictionnaire de termes avec exemples.
• Agrégats et invariants. Qui « tient » les règles et quelles opérations sont autorisées.
• Modèle de cohérence. Strong/CP pour l'argent, EC/causal pour les vitrines.
• Stockage et index. Sont choisis sous invariants et SLO.
• Les contrats de sortie. Événements/commandes, versions de schémas, SLO de livraison.

Extérieur : pas de dépendances SQL/tabulaires directes. La communication est par contrat.

6) Frontières et cohérence (PACELC)

A l'intérieur du BC : choisissez un modèle pour les invariants (Wallet - Strong, Betting - Strong à la réception).
Entre BC : le plus souvent eventual à travers des événements et des projections. Si vous avez besoin d'une vérification synchrone, une commande explicite avec une déduplication et une défaillance en cas d'indisponibilité (pas un appel REST « caché »).

7) Couche anticorruption (ACL)

La tâche de l'ACL est de ne pas laisser entrer la langue d'autrui et les données « sales » à l'intérieur de la Colombie-Britannique.

Mapping de schémas : externe 'PaymentStatus = SETTLED' → interne 'LedgerEntry (type = credit, reason = PsPSettle)'.
Validation et enrichissement : vérification des invariants, normalisation du timzon, des monnaies.
Versioning : prise en charge de 'schema _ version' du contrat externe, rétrocompatibilité.
Idempotence : par 'external _ id '/' operation _ id'.
Observabilité : balises de trace 'source', 'schema _ version', 'mapping _ id', DLQ pour les messages « toxiques ».

8) Limites et données : propriété, projections, API

Own....: Qui possède la « vérité » ? Seul le propriétaire change d'enregistrement. Les autres BC sont des modèles de lecture et des références.
Projections : tables dénormalisées sous lecture ; sont mis à jour à partir des événements.
API : commandes (muter chez le propriétaire) et requêtes (lire les projections). Pas d'updates « de bout en bout » des données des autres.

9) Évolution et versions

Événements et API - avec 'schema _ version' et la politique de compatibilité (additive + fallback).
Blue/Green par BC : le nouveau contrat 'v2' est publié en parallèle avec 'v1', le trafic se traduit progressivement.
Migrations : pour les changements majeurs - nouvelle projection/service, « pull à deux phases » lectures.

10) Tester les frontières

Tests de contrat : vérifiez que BC respecte le contrat publié (tests de production) et comprend correctement les autres (tests de consommation).
Property-based : invariants d'agrégats à l'intérieur de la Colombie-Britannique (bilan, limites, unicités).
Chaos sur les intégrations : retards, out-of-order, doublons, schema-evolution ; avoir un DLQ et un redrive sûr.
Tests NFR : p95/charge de pointe à la frontière (serveur d'événements/ACL).

11) Observation et SLO par les frontières

Métriques : throughput événements/commandes, 'projection _ lag _ ms',' dlq _ rate ', erreurs de mapping, API p95.
Tracing : balises obligatoires 'bc', 'tenant _ id', 'event _ id', 'opération _ id', 'schema _ version'.
Alert : dépassement de la marge de projection, augmentation des défaillances des commandes, « flap » du schéma (beaucoup de 'schema _ mismatch').

12) Multi-tenants et régions

"tenant _ id' - dans les clés de tous les événements et projections à la frontière.
Fairness : limites de publication/redrave per tenant pour que le « bruyant » ne perturbe pas les SLO des voisins.
Résidence : les données de la Colombie-Britannique vivent dans une région « domestique » ; cross-régional - agrégats/rapports.

13) Anti-modèles (ce qui conduit à une frontière floue)

Un « core-service » géant. Tout au même endroit → la lutte pour les transactions, les longues sorties, la faible autonomie.
Intégration tabulaire. SELECT direct dans les tables étrangères → la fragilité et le couplage selon le schéma.
Dual-write. Écrire simultanément en deux BC « pour la commodité » → divergence et sabotage des invariants.
Conformist par défaut. « Ils ont adopté le modèle des autres » → la fuite des sens des autres, l'impossibilité de l'évolution.
Appels synchrones cachés. REST-appel « quelque part à l'intérieur » sans contrat explicite et la date limite → une dépendance inattendue à l'accessibilité.

14) Exemple de contours (schéma verbal)

[Wallet/Ledger] <--CP, Leader, Transactions-->
publishes: WalletReserved/Committed v
[Betting] <--CP on bid taking-->
events: BetPlaced/Settled v
[Read Models/Analytics] <--EC projection-->

[Payments] --ACL--> [Wallet/Ledger]
[Provider Integration] --ACL--> [Game/Round]
[Compliance] <-events - [KYC/Identity], -> reports [Reporting]

15) Mini hyde au choix de la frontière

1. Formulez des invariants et déterminez qui peut les garantir.
2. Décrivez le dictionnaire (10-20 termes) et vérifiez que l'équipe a une compréhension.
3. Dessinez Context Map et les types de relations.
4. Décidez du modèle de cohérence à l'intérieur et sur les joints.
5. Concevoir des contrats (événements/équipes) et ACL.
6. Prévoir l'observabilité (métriques/tracing/alertes) et DLQ/redrave.
7. Effectuez des tests de contrat et des « tempêtes » (chaos) pour les intégrations.
8. Fixez la governance : qui parle la langue/le schéma, comment les changements sont apportés.

16) Chèque-liste avant la vente

• Chaque BC a un dictionnaire, des agrégats et des invariants.
• Les relations sont définies sur la carte contextuelle et les contrats sont documentés.
• Intégrations via événements/commandes et ACL, pas de dépendances SQL directes.
• Idempotence des commandes/événements ; il y a outbox/inbox et DLQ.
• Modèle de cohérence (à l'intérieur/entre BC) enregistré et testé.
• Versionation des schémas et stratégie d'interopérabilité (v1/v2).
• Les métriques Laga/Error/Performance et Alert sont configurées.
• Les politiques de multi-ténacité et de data residency sont respectées.
• Playbooks opérationnels : schema-mismatch, redrive, rebuild projections.

17) Recettes rapides

Argent et limites : BC séparé avec CP et transactions, API uniquement par équipe, événements comme résultat de vérité pour les lectures.
Fides/catalogues : BC avec EC, projections et cache, explicite « freshness ».
Intégrations avec des fournisseurs externes : toujours via ACL, événements/commandes, versioning de schémas.
Croissance de l'équipe : un BC est une équipe, l'équipe a un « propriétaire de la langue » et un « gardien des invariants ».
Refactoring monolithique : d'abord les contrats et l'ACL, puis la séparation physique.

Conclusion

Bounded Context n'est pas seulement un diagramme, mais un contrat de travail sur la langue, les règles et le mode d'évolution. Des limites claires réduisent la connectivité, accélèrent les changements et rendent le système prévisible en service. Diviser par sens et invariants, protéger les limites de l'ACL et des contrats, mesurer tout avec des métriques - et votre architecture restera flexible et fiable même avec la croissance rapide du domaine et de l'équipe.