[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f2jbof46i6k1w9":3,"$fiuqwbbd8tn2w":175},{"data":4},[5],{"id":6,"slug":7,"locale":8,"type":9,"title":10,"subtitle":11,"summary":12,"body":13,"primary_topic":14,"knowledge_status":15,"practical_validation":16,"workflow_status":17,"author_id":18,"published_at":19,"updated_at":19,"review_due_at":20,"canonical_url":21,"seo_title":10,"seo_description":12,"hero_asset_id":20,"reading_time":22,"version":23,"technology_versions":24,"review_frequency_days":25,"parent_content_id":26,"sort_in_parent":23,"hub_entry_status":27,"content_blocks":28,"hero_alt_text":21,"hero_caption":21,"hero_credit":21,"publication_scope":165,"access_level":166,"approved_at":167,"approved_by":168,"review_note":21,"home_enabled":169,"home_slot":170,"home_variant":171,"home_priority":172,"home_eyebrow":20,"home_valid_from":20,"home_valid_to":20,"home_image_asset_id":20,"promotion_kind":173,"sponsor_name":20,"sponsor_url":20,"sponsor_disclosure":174},"198691d9-d7aa-4d0f-a18f-47e847809dcd","modernizzazione-legacy-sanitario-bounded-context-data-ownership","it","CAPSULE","Bounded Context e Data Ownership: spezzare davvero il database condiviso","Il confine di un servizio nasce dal dominio e dalla proprietà del dato, non dal numero di tabelle.","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\nQuando 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.\nBounded Context\nUn 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.\nData Ownership\nOgni 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.\nEsempio sanitario\nPatient Identity\u002FEMPI possiede identità, identificativi, merge e matching.\n\nADT possiede Encounter, Admission, Transfer e Discharge.\n\nBed Management possiede Ward, Room, Bed e Occupancy.\n\nOrder Management possiede Order, Order Item, workflow e stato dell'ordine.\n\nClinical Record possiede note, valutazioni e documentazione clinica del proprio contesto.\n\nDocument Management possiede artefatto documentale e metadati di conservazione\u002Frecupero.\n\nDatabase per bounded context non significa una VM per servizio\nL'isolamento è prima di tutto logico e di ownership. Più contesti possono condividere lo stesso cluster PostgreSQL, ma con database\u002Fschema, ruoli e permessi separati. Order Entry non deve eseguire SELECT sulle tabelle ADT: usa API, eventi o proiezioni autorizzate.\nCome condividere informazioni\nQuery immediata → API sincrona del proprietario.\n\nNotifica di un fatto → Domain Event.\n\nVista aggregata → BFF\u002FAPI Composition o Read Model.\n\nReplica necessaria per performance → proiezione derivata, con ownership chiaramente distinta dal master.\n\nCriterio per trovare i confini\nCercare 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.\n\nIl vero obiettivo non è moltiplicare i database, ma rendere esplicito chi può decidere e modificare ogni informazione.","58ba728e-da9d-409d-a6c7-31325e3773a8","REVIEWED","NOT_PERFORMED","PUBLISHED","fbbfd4b6-f4c7-4740-94a6-f81eb8fbb1b2","2026-08-25T18:14:30.105Z",null,"",9,3,{},365,"776fc737-dda9-4c82-bd56-b6ba0b7148d6","AVAILABLE",[29,161],{"id":30,"type":31,"version":32,"doc":33},"50f640ef-db32-5972-9707-db4e18ceebf6","rich_text",1,{"type":34,"content":35},"doc",[36,44,49,54,58,63,67,72,112,117,121,126,152,157],{"type":37,"attrs":38,"content":40},"heading",{"level":39},2,[41],{"type":42,"text":43},"text","Perché il database condiviso è un problema architetturale",{"type":45,"content":46},"paragraph",[47],{"type":42,"text":48},"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.",{"type":37,"attrs":50,"content":51},{"level":39},[52],{"type":42,"text":53},"Bounded Context",{"type":45,"content":55},[56],{"type":42,"text":57},"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.",{"type":37,"attrs":59,"content":60},{"level":39},[61],{"type":42,"text":62},"Data Ownership",{"type":45,"content":64},[65],{"type":42,"text":66},"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.",{"type":37,"attrs":68,"content":69},{"level":39},[70],{"type":42,"text":71},"Esempio sanitario",{"type":73,"content":74},"bulletList",[75,82,88,94,100,106],{"type":76,"content":77},"listItem",[78],{"type":45,"content":79},[80],{"type":42,"text":81},"Patient Identity\u002FEMPI possiede identità, identificativi, merge e matching.",{"type":76,"content":83},[84],{"type":45,"content":85},[86],{"type":42,"text":87},"ADT possiede Encounter, Admission, Transfer e Discharge.",{"type":76,"content":89},[90],{"type":45,"content":91},[92],{"type":42,"text":93},"Bed Management possiede Ward, Room, Bed e Occupancy.",{"type":76,"content":95},[96],{"type":45,"content":97},[98],{"type":42,"text":99},"Order Management possiede Order, Order Item, workflow e stato dell'ordine.",{"type":76,"content":101},[102],{"type":45,"content":103},[104],{"type":42,"text":105},"Clinical Record possiede note, valutazioni e documentazione clinica del proprio contesto.",{"type":76,"content":107},[108],{"type":45,"content":109},[110],{"type":42,"text":111},"Document Management possiede artefatto documentale e metadati di conservazione\u002Frecupero.",{"type":37,"attrs":113,"content":114},{"level":39},[115],{"type":42,"text":116},"Database per bounded context non significa una VM per servizio",{"type":45,"content":118},[119],{"type":42,"text":120},"L'isolamento è prima di tutto logico e di ownership. Più contesti possono condividere lo stesso cluster PostgreSQL, ma con database\u002Fschema, ruoli e permessi separati. Order Entry non deve eseguire SELECT sulle tabelle ADT: usa API, eventi o proiezioni autorizzate.",{"type":37,"attrs":122,"content":123},{"level":39},[124],{"type":42,"text":125},"Come condividere informazioni",{"type":73,"content":127},[128,134,140,146],{"type":76,"content":129},[130],{"type":45,"content":131},[132],{"type":42,"text":133},"Query immediata → API sincrona del proprietario.",{"type":76,"content":135},[136],{"type":45,"content":137},[138],{"type":42,"text":139},"Notifica di un fatto → Domain Event.",{"type":76,"content":141},[142],{"type":45,"content":143},[144],{"type":42,"text":145},"Vista aggregata → BFF\u002FAPI Composition o Read Model.",{"type":76,"content":147},[148],{"type":45,"content":149},[150],{"type":42,"text":151},"Replica necessaria per performance → proiezione derivata, con ownership chiaramente distinta dal master.",{"type":37,"attrs":153,"content":154},{"level":39},[155],{"type":42,"text":156},"Criterio per trovare i confini",{"type":45,"content":158},[159],{"type":42,"text":160},"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.",{"id":162,"type":163,"version":32,"text":164},"f61fefcb-c777-5dbf-aad5-4b904de7269a","callout","Il vero obiettivo non è moltiplicare i database, ma rendere esplicito chi può decidere e modificare ogni informazione.","PORTAL","ANONYMOUS","2026-08-25T18:14:28.737Z","794a9185-136c-4415-ab23-cd144eb5870e",false,"LATEST","AUTO",0,"EDITORIAL","Sponsorizzato",{"sources":176,"secondaryTopics":177,"tags":178,"primaryTopic":179,"technologies":183},[],[],[],[180],{"id":14,"name":181,"slug":182},"Software Architecture","software-architecture",[]]