[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f2s9p634v3khvk":3,"$f3e1gy17805hwr":176},{"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":166,"access_level":167,"approved_at":168,"approved_by":169,"review_note":21,"home_enabled":170,"home_slot":171,"home_variant":172,"home_priority":173,"home_eyebrow":20,"home_valid_from":20,"home_valid_to":20,"home_image_asset_id":20,"promotion_kind":174,"sponsor_name":20,"sponsor_url":20,"sponsor_disclosure":175},"72a03bdf-0b92-4f4d-9174-178d6aa0b64d","modernizzazione-legacy-sanitario-event-driven","it","CAPSULE","Event-Driven Architecture: eventi di dominio senza rendere tutto asincrono","Usare eventi per fatti avvenuti e API sincrone quando serve una risposta immediata.","L'Event-Driven Architecture disaccoppia bounded context attraverso fatti di dominio, ma richiede una scelta consapevole tra sincrono e asincrono.","Evento significa fatto, non comando mascherato\nUn Domain Event descrive qualcosa che è già accaduto nel dominio: PatientAdmitted, PatientTransferred, OrderPlaced, ResultAvailable, DocumentSigned. Il producer non dice ai consumer cosa devono fare; pubblica un fatto con un significato stabile.\nQuando usare comunicazione asincrona\nPiù bounded context devono reagire allo stesso fatto.\n\nIl producer non deve attendere il completamento di tutti i consumer.\n\nÈ accettabile una breve eventual consistency.\n\nSi vuole ridurre l'accoppiamento temporale: un consumer può essere momentaneamente indisponibile.\n\nQuando preferire il sincrono\nL'utente ha bisogno della risposta per proseguire il caso d'uso.\n\nServe validare una precondizione prima di confermare il comando.\n\nLa consistenza deve essere immediata nel confine transazionale.\n\nUna semplice query al proprietario del dato è più chiara di un meccanismo di replica.\n\nEsempio\nADT conferma un ricovero nella propria transazione. Dopo il commit pubblica PatientAdmitted. Bed Management prepara l'occupazione, Clinical Record inizializza il contesto di reparto e Notification valuta eventuali comunicazioni. ADT non deve chiamare in sequenza tre API e restare bloccato dal servizio meno disponibile.\nContratto dell'evento\nUn evento deve avere identificatore, tipo\u002Fversione, aggregateId, timestamp, correlationId e payload minimo sufficiente. Evitare di copiare nell'evento l'intero documento paziente solo per comodità: ogni campo duplicato aumenta accoppiamento e rischi di privacy.\nEventual consistency non significa incoerenza incontrollata\nIl sistema deve rendere osservabili ritardi, retry, dead letter e lag dei consumer. Le UI possono mostrare stati intermedi espliciti. Per processi che attraversano più contesti e richiedono compensazioni, può essere opportuno un Process Manager\u002FSaga.\nErrore frequente\nSostituire ogni HTTP con RabbitMQ non crea un'architettura migliore: sposta soltanto l'accoppiamento dentro messaggi più difficili da tracciare.\n\nIl complemento necessario\nSe l'evento nasce dalla stessa modifica salvata nel database, il Transactional Outbox evita il dual write tra commit DB e publish sul broker.\n\nIl principio guida è semplice: query e decisioni immediate restano sincrone; fatti di dominio e reazioni indipendenti sono ottimi candidati per eventi.","58ba728e-da9d-409d-a6c7-31325e3773a8","REVIEWED","NOT_PERFORMED","PUBLISHED","fbbfd4b6-f4c7-4740-94a6-f81eb8fbb1b2","2026-08-25T18:17:04.126Z",null,"",8,3,{},365,"776fc737-dda9-4c82-bd56-b6ba0b7148d6",-27,"AVAILABLE",[30,162],{"id":31,"type":32,"version":33,"doc":34},"9ed4290b-9cae-598d-b1c3-a4fe189ac6d5","rich_text",1,{"type":35,"content":36},"doc",[37,45,50,55,83,88,114,119,123,128,132,137,141,146,153,158],{"type":38,"attrs":39,"content":41},"heading",{"level":40},2,[42],{"type":43,"text":44},"text","Evento significa fatto, non comando mascherato",{"type":46,"content":47},"paragraph",[48],{"type":43,"text":49},"Un Domain Event descrive qualcosa che è già accaduto nel dominio: PatientAdmitted, PatientTransferred, OrderPlaced, ResultAvailable, DocumentSigned. Il producer non dice ai consumer cosa devono fare; pubblica un fatto con un significato stabile.",{"type":38,"attrs":51,"content":52},{"level":40},[53],{"type":43,"text":54},"Quando usare comunicazione asincrona",{"type":56,"content":57},"bulletList",[58,65,71,77],{"type":59,"content":60},"listItem",[61],{"type":46,"content":62},[63],{"type":43,"text":64},"Più bounded context devono reagire allo stesso fatto.",{"type":59,"content":66},[67],{"type":46,"content":68},[69],{"type":43,"text":70},"Il producer non deve attendere il completamento di tutti i consumer.",{"type":59,"content":72},[73],{"type":46,"content":74},[75],{"type":43,"text":76},"È accettabile una breve eventual consistency.",{"type":59,"content":78},[79],{"type":46,"content":80},[81],{"type":43,"text":82},"Si vuole ridurre l'accoppiamento temporale: un consumer può essere momentaneamente indisponibile.",{"type":38,"attrs":84,"content":85},{"level":40},[86],{"type":43,"text":87},"Quando preferire il sincrono",{"type":56,"content":89},[90,96,102,108],{"type":59,"content":91},[92],{"type":46,"content":93},[94],{"type":43,"text":95},"L'utente ha bisogno della risposta per proseguire il caso d'uso.",{"type":59,"content":97},[98],{"type":46,"content":99},[100],{"type":43,"text":101},"Serve validare una precondizione prima di confermare il comando.",{"type":59,"content":103},[104],{"type":46,"content":105},[106],{"type":43,"text":107},"La consistenza deve essere immediata nel confine transazionale.",{"type":59,"content":109},[110],{"type":46,"content":111},[112],{"type":43,"text":113},"Una semplice query al proprietario del dato è più chiara di un meccanismo di replica.",{"type":38,"attrs":115,"content":116},{"level":40},[117],{"type":43,"text":118},"Esempio",{"type":46,"content":120},[121],{"type":43,"text":122},"ADT conferma un ricovero nella propria transazione. Dopo il commit pubblica PatientAdmitted. Bed Management prepara l'occupazione, Clinical Record inizializza il contesto di reparto e Notification valuta eventuali comunicazioni. ADT non deve chiamare in sequenza tre API e restare bloccato dal servizio meno disponibile.",{"type":38,"attrs":124,"content":125},{"level":40},[126],{"type":43,"text":127},"Contratto dell'evento",{"type":46,"content":129},[130],{"type":43,"text":131},"Un evento deve avere identificatore, tipo\u002Fversione, aggregateId, timestamp, correlationId e payload minimo sufficiente. Evitare di copiare nell'evento l'intero documento paziente solo per comodità: ogni campo duplicato aumenta accoppiamento e rischi di privacy.",{"type":38,"attrs":133,"content":134},{"level":40},[135],{"type":43,"text":136},"Eventual consistency non significa incoerenza incontrollata",{"type":46,"content":138},[139],{"type":43,"text":140},"Il sistema deve rendere osservabili ritardi, retry, dead letter e lag dei consumer. Le UI possono mostrare stati intermedi espliciti. Per processi che attraversano più contesti e richiedono compensazioni, può essere opportuno un Process Manager\u002FSaga.",{"type":38,"attrs":142,"content":143},{"level":40},[144],{"type":43,"text":145},"Errore frequente",{"type":147,"content":148},"blockquote",[149],{"type":46,"content":150},[151],{"type":43,"text":152},"Sostituire ogni HTTP con RabbitMQ non crea un'architettura migliore: sposta soltanto l'accoppiamento dentro messaggi più difficili da tracciare.",{"type":38,"attrs":154,"content":155},{"level":40},[156],{"type":43,"text":157},"Il complemento necessario",{"type":46,"content":159},[160],{"type":43,"text":161},"Se l'evento nasce dalla stessa modifica salvata nel database, il Transactional Outbox evita il dual write tra commit DB e publish sul broker.",{"id":163,"type":164,"version":33,"text":165},"30a60001-690d-5516-9a18-ae305026d19d","callout","Il principio guida è semplice: query e decisioni immediate restano sincrone; fatti di dominio e reazioni indipendenti sono ottimi candidati per eventi.","PORTAL","ANONYMOUS","2026-08-25T18:17:02.699Z","794a9185-136c-4415-ab23-cd144eb5870e",false,"LATEST","AUTO",0,"EDITORIAL","Sponsorizzato",{"sources":177,"secondaryTopics":178,"tags":179,"primaryTopic":180,"technologies":184},[],[],[],[181],{"id":14,"name":182,"slug":183},"Software Architecture","software-architecture",[]]