Applicare approcci CQRS e CQS in un microservizio DDD in eShopOnContainers

La progettazione del microservizio di ordinamento nell'applicazione di riferimento eShopOnContainers si basa sui principi CQRS. Tuttavia, usa l'approccio più semplice, che separa le query dai comandi e usa lo stesso database per entrambe le azioni.

L'essenza di questi modelli, e il punto importante qui, è che le query sono idempotenti: indipendentemente dal numero di query su un sistema, lo stato del sistema non cambierà. In altre parole, le query sono prive di effetti collaterali.

Pertanto, è possibile usare un modello di dati "reads" diverso rispetto al modello di dominio "scritture" della logica transazionale, anche se i microservizi di ordinamento usano lo stesso database. Di conseguenza, si tratta di un approccio CQRS semplificato.

D'altra parte, i comandi, che attivano transazioni e aggiornamenti dei dati, modificano lo stato nel sistema. Con i comandi, è necessario prestare attenzione quando si gestiscono complessità e regole business in continua evoluzione. Questa è la posizione in cui si vogliono applicare tecniche DDD per avere un sistema modellato meglio.

I modelli DDD presentati in questa guida non devono essere applicati universalmente. Introducono vincoli sulla progettazione. Questi vincoli offrono vantaggi come una qualità superiore nel tempo, soprattutto nei comandi e in altro codice che modifica lo stato del sistema. Tuttavia, questi vincoli aggiungono complessità con un minor numero di vantaggi per la lettura e l'esecuzione di query sui dati.

Uno di questi modelli è il modello aggregato, che verrà esaminato più avanti nelle sezioni successive. Brevemente, nel modello Aggregato si considerano molti oggetti di dominio come una singola unità in seguito alla relazione nel dominio. Non è sempre possibile ottenere vantaggi da questo modello nelle query; può aumentare la complessità della logica di query. Per le query di sola lettura, non si ottengono i vantaggi della gestione di più oggetti come un'unica aggregazione. Si ottiene solo la complessità.

Come illustrato nella figura 7-2 della sezione precedente, questa guida suggerisce l'uso di modelli DDD solo nell'area transazionale/aggiornamenti del microservizio, ovvero come attivato dai comandi. Le query possono seguire un approccio più semplice e devono essere separate dai comandi, seguendo un approccio CQRS.

Per implementare il lato "interrogazioni", puoi scegliere tra molti approcci, come un ORM completo come EF Core, proiezioni di AutoMapper, stored procedure, viste, viste materializzate o un micro ORM.

In questa guida e in eShopOnContainers (in particolare il microservizio di ordinamento) abbiamo scelto di implementare query dritte usando un micro ORM come Dapper. Questa guida consente di implementare qualsiasi query basata su istruzioni SQL per ottenere prestazioni ottimali, grazie a un framework leggero con un sovraccarico ridotto.

Quando si usa questo approccio, gli aggiornamenti al modello che influiscono sul modo in cui le entità vengono mantenute in un database SQL necessitano anche di aggiornamenti separati per le query SQL usate da Dapper o qualsiasi altro approccio separato (non EF) all'esecuzione di query.

I modelli CQRS e DDD non sono architetture di primo livello

È importante comprendere che CQRS e la maggior parte dei modelli DDD (come i livelli DDD o un modello di dominio con aggregazioni) non sono stili architetturali, ma solo modelli di architettura. I microservizi, SOA e l'architettura basata su eventi (EDA) sono esempi di stili architetturali. Descrivono un sistema di molti componenti, ad esempio molti microservizi. I modelli CQRS e DDD descrivono qualcosa all'interno di un singolo sistema o componente; in questo caso, qualcosa all'interno di un microservizio.

Diversi contesti delimitati (BCS) usano modelli diversi. Hanno responsabilità diverse e questo porta a soluzioni diverse. Vale la pena sottolineare che forzare lo stesso modello ovunque porta a fallimento. Non usare modelli CQRS e DDD ovunque. Molti sottosistemi, BCS o microservizi sono più semplici e possono essere implementati più facilmente usando semplici servizi CRUD o usando un altro approccio.

Esiste una sola architettura dell'applicazione: l'architettura del sistema o dell'applicazione end-to-end che si sta progettando, ad esempio l'architettura dei microservizi. Tuttavia, la progettazione di ogni contesto delimitato o microservizio all'interno di tale applicazione riflette i propri compromessi e decisioni di progettazione interne a livello di modelli di architettura. Non provare ad applicare gli stessi modelli architetturali di CQRS o DDD ovunque.

Risorse aggiuntive

• Martin Fowler. CQRS
  https://martinfowler.com/bliki/CQRS.html

• Greg Young. Documenti CQRS
  https://cqrs.files.wordpress.com/2010/11/cqrs_documents.pdf

• Udi Dahan. CQRS spiegato
  https://udidahan.com/2009/12/09/clarified-cqrs/