Il bounded context è la stessa cosa di un microservizio?

Sono concetti collegati ma distinti. Il bounded context è un confine di modellazione, definisce dove un termine di business ha un unico significato coerente. Un microservizio è un confine di deployment tecnico. Spesso coincidono, ma un bounded context può contenere più servizi, o un servizio può attraversare più bounded context se progettato male.

Avere più bounded context significa avere dati duplicati?

Non necessariamente in modo problematico. Ogni contesto ha il proprio modello dello stesso concetto di business (per esempio "cliente"), ma il contratto esplicito di traduzione tra un contesto e l'altro evita che questa pluralità diventi incoerenza silenziosa.

Cos'è un bounded context?

Confine esplicito entro cui un termine di business ha un unico significato coerente, senza forzare un modello dati unico globale.

Il bounded context è il confine esplicito entro cui un termine di business ha un unico significato coerente, e fuori da quel confine può significare qualcos'altro senza che sia un errore di modellazione. Il concetto nasce nel Domain-Driven Design di Eric Evans: invece di inseguire un modello dati unico che descriva "il cliente" o "l'ordine" per tutta l'azienda, si accetta che ogni area di business abbia il proprio modello, valido e coerente al suo interno. Un esempio tipico: "cliente" in vendite è un lead con uno storico di trattative, in fatturazione è un'anagrafica con partita IVA e condizioni di pagamento, in supporto è un contratto con SLA e ticket aperti. Sono tre modelli diversi dello stesso termine, e va bene così: ognuno serve bene il proprio contesto invece di essere un compromesso che non serve bene nessuno.

Perché un modello unico globale fallisce

Il tentativo classico, e quasi sempre fallimentare, è costruire un'unica entità "cliente" che vada bene per vendite, fatturazione e supporto insieme. Il risultato è un modello con decine di campi opzionali, regole di business contraddittorie e un team di modellazione che media all'infinito tra reparti con esigenze incompatibili. Il bounded context rovescia l'approccio: ogni contesto ha il proprio modello, con il proprio linguaggio, e le traduzioni tra un contesto e l'altro sono esplicite, non nascoste dentro una tabella condivisa che nessuno controlla davvero. Non è frammentazione incontrollata, è il riconoscimento che un modello dati riflette come un'organizzazione lavora, e un'organizzazione con più funzioni ha, legittimamente, più di un modello.

Un esempio enterprise

Un gruppo industriale con vendite dirette, un servizio di post-vendita e una funzione finance separati smette di inseguire un'anagrafica cliente unica valida ovunque. Definisce invece tre bounded context, ognuno con il proprio modello di "cliente", e un contratto esplicito su cosa e come si traduce da un contesto all'altro (per esempio quale identificativo unico collega il lead di vendita alla fattura). Il risultato è meno tempo speso a mediare un modello globale impossibile, e più chiarezza su chi possiede cosa.

Perché conta per chi decide

Applicato alla pratica recente, il principio del bounded context è ciò che dà forma a un buon data product: un data product ben progettato incarna un bounded context, e offre a un consumatore o a un agente AI uno slice di dati con semantica coerente, invece di un dataset ambiguo esteso a tutta l'azienda. Lo stesso principio guida un buon semantic layer: rispettare i bounded context significa accettare che "cliente attivo" possa avere definizioni diverse per contesti diversi, invece di forzare una definizione identica ovunque solo per semplicità di implementazione. Chi decide su architettura dati o su progetti AI ne ricava un criterio pratico: prima di unificare un modello, chiedersi se i contesti che si vogliono unire sono davvero lo stesso contesto di business, o solo la stessa tabella.