[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f1rwwpty20tjgr":3,"$f318kfdtq7iusy":160},{"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":27,"hub_entry_status":28,"content_blocks":29,"hero_alt_text":21,"hero_caption":21,"hero_credit":21,"publication_scope":150,"access_level":151,"approved_at":152,"approved_by":153,"review_note":21,"home_enabled":154,"home_slot":155,"home_variant":156,"home_priority":157,"home_eyebrow":20,"home_valid_from":20,"home_valid_to":20,"home_image_asset_id":20,"promotion_kind":158,"sponsor_name":20,"sponsor_url":20,"sponsor_disclosure":159},"faf9f968-0a57-481f-bc61-d7765a74a12d","modernizzazione-legacy-sanitario-context-map","it","CAPSULE","Context Map: rendere esplicite le relazioni tra i bounded context","Non basta dividere il sistema: bisogna descrivere come i contesti collaborano e chi influenza chi.","La Context Map di DDD documenta relazioni, dipendenze e traduzioni tra bounded context, diventando una guida concreta per integrazioni e migrazione del legacy.","Perché serve\nDopo aver individuato Patient Identity, ADT, Bed Management, Order Management e Clinical Record, resta una domanda fondamentale: come si relazionano? Se questa risposta rimane implicita, il sistema ricrea dipendenze nascoste attraverso API, database o messaggi.\nCosa documentare\nUpstream e downstream: chi possiede il concetto e chi lo consuma.\n\nTipo di relazione: API sincrona, evento, Read Model, ACL, Open Host Service.\n\nContratto: identificativi, versioni, SLA, semantica e compatibilità.\n\nAuthority: quale sistema è source of truth in ogni fase della migrazione.\n\nPolitica di errore: cosa accade se l'upstream è indisponibile.\n\nEsempio\nPatient Identity è upstream dell'identità canonica; ADT conserva patientId ma non ridefinisce il paziente. ADT è upstream dell'episodio e pubblica PatientTransferred; Bed Management consuma l'evento e mantiene la propria Occupancy. Order Entry può interrogare ADT per verificare l'episodio ma non accede alle sue tabelle.\nRelazioni utili durante la modernizzazione\nAnti-Corruption Layer verso legacy con modello incompatibile.\n\nPublished Language per eventi\u002FAPI con semantica condivisa e versionata.\n\nOpen Host Service per un servizio che espone un contratto stabile a più consumer.\n\nConformist solo quando accettare il modello upstream è una scelta consapevole e poco rischiosa.\n\nContext Map come strumento di retirement\nAggiungendo alla mappa lo stato LEGACY\u002FSHADOW\u002FDUAL-RUN\u002FAUTHORITATIVE\u002FRETIRED, si vede quali dipendenze impediscono lo spegnimento di un componente. Il retirement diventa una proprietà verificabile della mappa, non una decisione improvvisata a fine progetto.\nUna mappa viva\nLa Context Map deve essere versionata e aggiornata insieme ai contratti. Diagrammi belli ma non collegati a owner, repository, API ed eventi diventano rapidamente obsoleti. È utile mantenerla vicina all'Architecture Decision Record e ai cataloghi di integrazione.\n\nUna buona Context Map mostra non solo le scatole, ma soprattutto le frecce: ownership, semantica, protocollo e direzione della dipendenza.","58ba728e-da9d-409d-a6c7-31325e3773a8","REVIEWED","NOT_PERFORMED","PUBLISHED","fbbfd4b6-f4c7-4740-94a6-f81eb8fbb1b2","2026-08-25T18:12:08.544Z",null,"",8,3,{},365,"776fc737-dda9-4c82-bd56-b6ba0b7148d6",2,"AVAILABLE",[30,146],{"id":31,"type":32,"version":33,"doc":34},"1c8c8910-62ce-569d-ac76-c9ddff3d932b","rich_text",1,{"type":35,"content":36},"doc",[37,44,49,54,88,93,97,102,128,133,137,142],{"type":38,"attrs":39,"content":40},"heading",{"level":27},[41],{"type":42,"text":43},"text","Perché serve",{"type":45,"content":46},"paragraph",[47],{"type":42,"text":48},"Dopo aver individuato Patient Identity, ADT, Bed Management, Order Management e Clinical Record, resta una domanda fondamentale: come si relazionano? Se questa risposta rimane implicita, il sistema ricrea dipendenze nascoste attraverso API, database o messaggi.",{"type":38,"attrs":50,"content":51},{"level":27},[52],{"type":42,"text":53},"Cosa documentare",{"type":55,"content":56},"bulletList",[57,64,70,76,82],{"type":58,"content":59},"listItem",[60],{"type":45,"content":61},[62],{"type":42,"text":63},"Upstream e downstream: chi possiede il concetto e chi lo consuma.",{"type":58,"content":65},[66],{"type":45,"content":67},[68],{"type":42,"text":69},"Tipo di relazione: API sincrona, evento, Read Model, ACL, Open Host Service.",{"type":58,"content":71},[72],{"type":45,"content":73},[74],{"type":42,"text":75},"Contratto: identificativi, versioni, SLA, semantica e compatibilità.",{"type":58,"content":77},[78],{"type":45,"content":79},[80],{"type":42,"text":81},"Authority: quale sistema è source of truth in ogni fase della migrazione.",{"type":58,"content":83},[84],{"type":45,"content":85},[86],{"type":42,"text":87},"Politica di errore: cosa accade se l'upstream è indisponibile.",{"type":38,"attrs":89,"content":90},{"level":27},[91],{"type":42,"text":92},"Esempio",{"type":45,"content":94},[95],{"type":42,"text":96},"Patient Identity è upstream dell'identità canonica; ADT conserva patientId ma non ridefinisce il paziente. ADT è upstream dell'episodio e pubblica PatientTransferred; Bed Management consuma l'evento e mantiene la propria Occupancy. Order Entry può interrogare ADT per verificare l'episodio ma non accede alle sue tabelle.",{"type":38,"attrs":98,"content":99},{"level":27},[100],{"type":42,"text":101},"Relazioni utili durante la modernizzazione",{"type":55,"content":103},[104,110,116,122],{"type":58,"content":105},[106],{"type":45,"content":107},[108],{"type":42,"text":109},"Anti-Corruption Layer verso legacy con modello incompatibile.",{"type":58,"content":111},[112],{"type":45,"content":113},[114],{"type":42,"text":115},"Published Language per eventi\u002FAPI con semantica condivisa e versionata.",{"type":58,"content":117},[118],{"type":45,"content":119},[120],{"type":42,"text":121},"Open Host Service per un servizio che espone un contratto stabile a più consumer.",{"type":58,"content":123},[124],{"type":45,"content":125},[126],{"type":42,"text":127},"Conformist solo quando accettare il modello upstream è una scelta consapevole e poco rischiosa.",{"type":38,"attrs":129,"content":130},{"level":27},[131],{"type":42,"text":132},"Context Map come strumento di retirement",{"type":45,"content":134},[135],{"type":42,"text":136},"Aggiungendo alla mappa lo stato LEGACY\u002FSHADOW\u002FDUAL-RUN\u002FAUTHORITATIVE\u002FRETIRED, si vede quali dipendenze impediscono lo spegnimento di un componente. Il retirement diventa una proprietà verificabile della mappa, non una decisione improvvisata a fine progetto.",{"type":38,"attrs":138,"content":139},{"level":27},[140],{"type":42,"text":141},"Una mappa viva",{"type":45,"content":143},[144],{"type":42,"text":145},"La Context Map deve essere versionata e aggiornata insieme ai contratti. Diagrammi belli ma non collegati a owner, repository, API ed eventi diventano rapidamente obsoleti. È utile mantenerla vicina all'Architecture Decision Record e ai cataloghi di integrazione.",{"id":147,"type":148,"version":33,"text":149},"6d176cb0-a5c9-50a9-95a1-fc482f7781c7","callout","Una buona Context Map mostra non solo le scatole, ma soprattutto le frecce: ownership, semantica, protocollo e direzione della dipendenza.","PORTAL","ANONYMOUS","2026-08-25T18:12:07.043Z","794a9185-136c-4415-ab23-cd144eb5870e",false,"LATEST","AUTO",0,"EDITORIAL","Sponsorizzato",{"sources":161,"secondaryTopics":162,"tags":163,"primaryTopic":164,"technologies":168},[],[],[],[165],{"id":14,"name":166,"slug":167},"Software Architecture","software-architecture",[]]