Bounded Text e i limiti del dominio

Bounded Text (BC) è un bordo ben definito all'interno del quale opera un unico Ubiquitous Language, modelli e invarianti coerenti. All'interno del limite, i termini sono univoci (Puntata, Client, Limite), mentre all'esterno il contesto comunica con i contratti (eventi/comandi) e non trascina le code di significato degli altri. I limiti selezionati in modo corretto riducono la connettività, semplificano la scalabilità e accelerano l'evoluzione del prodotto.

1) Perché i limiti sono necessari

Riduzione del carico cognitivo. Il team funziona con un solo modello e una sola lingua, non con «tutto il business».
Isolamento degli invarianti. Le regole critiche (≥ 0, login unico) vivono in un unico luogo e sono protette da aggregazioni.
Gestione delle modifiche. L'evoluzione degli schemi/regole all'interno della BC non rompe il vicino - ci sono contratti chiari.
Prestazioni e affidabilità. All'interno della BC è possibile scegliere il modello di coerenza e lo storage adatto. all'esterno, proiezioni asincroni.

2) Come identificare Bounded Text

1. Event Storing - Rilasciare gli eventi di dominio «cosa è successo», quindi i comandi «cosa fare», quindi le unità «chi garantisce la regola».

2. Cluster di lingua: dove le parole e le regole coincidono stabilmente - potenziale BC. Dove la parolà Cliente "significa diverso (pagatore vs) sono contesti chiaramente diversi.

3. Invarianti e ownership: cosa non può essere violato e chi risponde? L'invariante è entrato nella BC che può garantirlo.

4. Flusso di valore: raggruppa i passaggi che cambiano spesso insieme: sono candidati per una sola BC.

5. Struttura org: se una parte viene eseguita da un comando separato con un singolo KPI, probabilmente è una singola BC (ma non il contrario: l'organigramma non deve dettare ciecamente il modello).

• La discussione sui termini («puntata», «biglietto», «round» sono significati diversi).
• L'invariante più caldo passa attraverso i servizi.
• Diversi SLO e ritmo di cambiamento.
• Dual-write tra i moduli per essere atomatici.

3) Contesti tipici (esempio di area oggetto)

Identity/KYC - Registrazione, livelli di verifica, stato di restrizione.
Wallet/Ledger - bilanci, cavi, riserve, valute.
Betting/Orders - ricezione, quotazione, calcolo.
Game/Round - ciclo di vita del round, risultati.
Bonus/Promo - ricevimenti, wager, conversione.
Payments - depositi/conclusioni, statuti di passerella.
Compliance/Reporting - Report, verifiche, vetrine regolatorie.
Catalog/Provider Integration - giochi, versioni, stati provider.
Analytics/Read Models - proiezioni e rappresentazioni materializzate.

4) Text Map - Come interagiscono i BC

• Customer–Supplier. Una BC (Supplier) fornisce eventi/dati, un'altra (Customer) modifica i propri modelli.
• Conformist. Customer accetta la lingua e il modello Supplier com'è (ad esempio, registro regolamentare).
• Partnership. Due BC evolvono sincronicamente il linguaggio e i contratti (spesso un team/roadmap).
• Shared Kernel. La libreria o l'aggancio minimo totale è versionata insieme; Usare con cautela.
• Anti-Corruption Layer (ACL). Un livello di protezione che traduce i modelli degli altri nella propria lingua.
• Open Host Service / Published Language. Protocolli/schemi pubblici, versionabili e documentati.

Pratica: per impostazione predefinita, utilizzare l'ACL e gli eventi asincroni; Conformist - solo se il provider impone lo standard, Shared Kernel è minimo e consapevole.

5) Limite = lingua + modello + invarianti + archiviazione

• Ubiquitous Language. Dizionario di termini con esempi.
• Aggregati e invarianti. Chi tiene le regole e quali operazioni sono autorizzate.
• Un modello di coerenza. Strong/CAP per il denaro, EC/causal per le vetrine.
• Magazzino e indici. Vengono scelti sotto invarianti e SLO.
• Contratti di uscita. Eventi/comandi, versioni di schemi, consegne SLO.

Non ci sono dipendenze SQL/tabelle dirette all'esterno. La comunicazione è attraverso un contratto.

6) Limiti e coerenza (PACELC)

All'interno di BC: seleziona il modello come invarianti (Wallet - Strong, Betting - Strong al ricevimento).
Tra BC: il più delle volte eventual attraverso eventi e proiezioni. Se si desidera la convalida sincrona, è un comando esplicito con deadline e guasto quando non disponibile (non nascosto).

7) Strato anticorruzione (ACL)

Il compito dell'ACL è quello di evitare che la lingua di qualcun altro e i dati «sporchi» entrino nella BC.

Mapping diagrammi " " esterno "interno" (type = Credit, ) ".
Validazione e arricchimento: controllo degli invarianti, normalizzazione del timesone, delle valute.
Versioning: supporto dì schema _ version "del contratto esterno, compatibilità inversa.
Idampotenza per «esternal _ id »/« operation _ id».
Osservabilità: tag trace «source», «schema _ variante», «mapping _ id», DLQ per i messaggi «velenosi».

8) Limiti e dati: proprietà, proiezioni, API

Chi possiede la verità? Solo il proprietario cambia la registrazione. Gli altri modelli e riferimenti BC sono i modelli read.
Proiezioni: tabelle denormalizzate in lettura; vengono aggiornati dagli eventi.
API - Comandi (mutati dal proprietario) e query (leggi proiezioni). Niente update passanti di dati estranei.

9) Evoluzione e versioni

Eventi e API - con'schema _ version'e criteri di compatibilità (additive + fallback).
Il nuovo contratto «v2» viene pubblicato parallelamente a «v1» e il traffico viene tradotto gradualmente.
Migrazioni: per modifiche serie - nuova proiezione/servizio, «maglioncino a due fasi» letture.

10) Test dei limiti

Contract test - Verifica che la BC rispetti il contratto pubblicato (producer test) e comprenda correttamente quello degli altri (consumer test).
Property-based - Invarianti di aggregazione all'interno di BC (bilanciamento, limiti, unicità).
Chaos sulle integrazioni: ritardi, out-of-order, duplicati, schema-evolution; la presenza di un DLQ e di un redrave sicuro.
Test NFR: p95/picco limite (server eventi/ACL).

11) Osservabilità e SLO ai confini

Metriche: throughput eventi/comandi, 'progection _ lag _ ms',' dlq _ rate ', errori di mapping, p95 API.
Tracing: tag obbligatori «bc», «tenant _ id», «event _ id», «operation _ id», «schema _ variante».
Alert: eccesso di proiezione, aumento dei guasti di comando, schema «flap» (molti «schema _ mismatch»).

12) Multi-tenente e regioni

«tenant _ id» è la chiave di tutti gli eventi e le proiezioni al confine.
Fairness: limiti per pubblicazioni/redrave per tenant in modo che il rumore non rompa la SLO dei vicini.
Residency: i dati della BC vivono in una regione «domestica»; cross-regionale - aggregazioni/rapporti.

13) Anti-pattern (che porta a un limite sfocato)

Un gigantesco core-service. Tutti in un unico posto, lotta per transazioni, rilasci lunghi, scarsa autonomia.
Integrazioni tabellari. SELECT diretto nelle tabelle altrui → la fragilità e il cupling secondo lo schema.
Dual-write. Scrivere contemporaneamente in due BC «per agevolare» le discrepanze e sabotare gli invarianti.
Conformist predefinito. «Adottato un modello estraneo com'è», fuga di significati altrui, impossibilità di evoluzione.
Chiamate sincroni nascoste. La chiamata REST'da qualche parte senza un contratto esplicito e la deadline è una dipendenza inaspettata dalla disponibilità.

14) Esempio di tracciati (schema verbale)

[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 per la scelta del confine

1. Formate gli invarianti e identificate chi può garantirli.
2. Descrivere il dizionario (10-20 termini) e verificare che il comando abbia la stessa comprensione.
3. Disegnare Text Map e i tipi di relazione.
4. Risolvere il modello di coerenza all'interno e ai giunti.
5. Progettare contratti (eventi/comandi) e ACL.
6. Assicurati di osservare (metriche/tracking/alert) e DLQ/redrave.
7. Eseguire contract-test e «tempesta» per le integrazioni.
8. Fissa governance: chi conosce la lingua/schema, come vengono apportate le modifiche.

16) Foglio di assegno prima della vendita

• Ogni BC ha un dizionario, aggregati e invarianti.
• È stata definita una relazione su Text Map e sono stati documentati i contratti.
• Integrazioni attraverso eventi/comandi e ACL, nessuna dipendenza SQL diretta.
• Idampotenza dei comandi/eventi; ci sono outbox/inbox e DLQ.
• Il modello di coerenza (interno/tra BC) è stato fissato e testato.
• Versioning degli schemi e strategia di compatibilità (v1/v2).
• Le metriche/errori/prestazioni e gli alert sono configurati.
• I criteri multi-tenanti e data-residency sono stati rispettati.
• Playbook operativi: schema-mismatch, redrive, rebuild proiezioni.

17) Ricette veloci

Denaro e limiti: una BC separata con le transazioni e le transazioni, API solo i comandi, eventi come esito della verità per le letture.
Fidi/directory: BC con EC, proiezioni e cache, nitide'freshness '.
Integrazioni con provider esterni: sempre tramite ACL, eventi/comandi, versioning degli schemi.
La crescita del team è che una BC è una sola squadra, la squadra ha «proprietario della lingua» e «custode degli invarianti».
Monolite di rifacimento, prima contratti e ACL, poi separazione fisica.

Conclusione

Bounded Text non è solo un grafico, ma un contratto di lavoro sul linguaggio, le regole e il modo di evoluzione. Limiti chiari riducono la connettività, accelerano i cambiamenti e rendono il sistema prevedibile in uso. Separare per senso e invarianti, proteggere i limiti dell'ACL e dei contratti, misurare tutte le metriche e mantenere l'architettura flessibile e affidabile anche se il dominio e il comando crescono rapidamente.