Bounded Context e Data Ownership: spezzare davvero il database condiviso
DDD e Data Ownership aiutano a separare identità paziente, episodio, letto, ordine e cartella clinica evitando database condivisi e dipendenze SQL tra moduli.
Perché il database condiviso è un problema architetturale
Quando più moduli leggono e scrivono direttamente le stesse tabelle o collection, il database diventa contemporaneamente modello di dominio, API e meccanismo di integrazione. Una modifica allo schema può rompere consumer sconosciuti e nessun team possiede davvero il dato.
Bounded Context
Un Bounded Context è un confine entro cui un modello ha significato coerente e un linguaggio preciso. Non coincide automaticamente con un microservizio. Può iniziare come modulo di un modular monolith e diventare un servizio autonomo quando esistono motivi di ciclo di vita, scalabilità, rischio o organizzazione.
Data Ownership
Ogni concetto deve avere un source of truth dichiarato. Gli altri contesti possono mantenere identificativi, snapshot giustificati o proiezioni, ma non devono modificare direttamente il database del proprietario.
Esempio sanitario
Patient Identity/EMPI possiede identità, identificativi, merge e matching.
ADT possiede Encounter, Admission, Transfer e Discharge.
Bed Management possiede Ward, Room, Bed e Occupancy.
Order Management possiede Order, Order Item, workflow e stato dell'ordine.
Clinical Record possiede note, valutazioni e documentazione clinica del proprio contesto.
Document Management possiede artefatto documentale e metadati di conservazione/recupero.
Database per bounded context non significa una VM per servizio
L'isolamento è prima di tutto logico e di ownership. Più contesti possono condividere lo stesso cluster PostgreSQL, ma con database/schema, ruoli e permessi separati. Order Entry non deve eseguire SELECT sulle tabelle ADT: usa API, eventi o proiezioni autorizzate.
Come condividere informazioni
Query immediata → API sincrona del proprietario.
Notifica di un fatto → Domain Event.
Vista aggregata → BFF/API Composition o Read Model.
Replica necessaria per performance → proiezione derivata, con ownership chiaramente distinta dal master.
Criterio per trovare i confini
Cercare invarianti, termini con significato diverso, ritmi di cambiamento, responsabilità organizzative e transazioni che devono restare atomiche. Il numero di controller o collection non è un criterio affidabile per definire un bounded context.