CQRS, Read Model e BFF: comporre viste senza join tra database
CQRS, Read Model, API Composition e BFF permettono UI e reporting ricchi senza accessi SQL diretti tra bounded context.
Il problema
Una UI sanitaria può dover mostrare identità paziente, episodio, letto, ordini e ultimi documenti nella stessa schermata. Se ogni contesto possiede il proprio database, la tentazione è creare un database condiviso di nuovo o consentire join cross-schema. Questo annulla il Data Ownership.
API Composition
Un BFF o servizio di composizione può interrogare in parallelo le API dei proprietari e assemblare una risposta orientata alla schermata. È adatto quando il numero di fonti è limitato, i dati devono essere freschi e la latenza resta sotto controllo.
Read Model
Per dashboard, liste ad alto volume, ricerca o reporting può essere meglio mantenere una proiezione denormalizzata costruita dagli eventi. Il Read Model è derivato: non è source of truth e può essere ricostruito dai dati/eventi autorevoli.
CQRS
Command Query Responsibility Segregation separa il modello usato per cambiare lo stato da quello usato per leggerlo. Non implica necessariamente Event Sourcing e non richiede due tecnologie diverse. Significa che il modello di scrittura protegge invarianti mentre il modello di lettura è ottimizzato per le query.
BFF
Il Backend for Frontend espone API pensate per un particolare frontend o Application Shell. Può comporre dati, propagare identità/autorizzazioni e ridurre round trip. Non deve diventare il luogo dove si decidono ricoveri, ordini o regole cliniche: quelle restano nei bounded context.
Esempio
EMPI espone identità canonica.
ADT espone episodio corrente.
Bed Management espone occupazione.
Order Entry espone ordini aperti.
Un Patient Workspace Read Model combina gli eventi necessari e serve rapidamente la home clinica.
Consistenza
Una proiezione asincrona può essere leggermente in ritardo. L'interfaccia deve tollerarlo e, per dati critici che richiedono conferma immediata, può interrogare direttamente il source of truth. CQRS non elimina la necessità di decidere quali informazioni possono essere eventualmente consistenti.
Reporting
Anche il reporting dovrebbe consumare API/proiezioni dedicate invece di replicare l'intero catalogo di controller o interrogare direttamente i database degli altri servizi. Questo consente di evolvere i domini senza rompere centinaia di report.