Aplicarea abordarilor CQRS si CQS intr-un microserviciu DDD in eShopOnContainers

• 13.01.2021
• 3 minute de citit

In acest articol

Proiectarea microserviciului de comanda la aplicatia de referinta eShopOnContainers se bazeaza pe principiile CQRS. Cu toate acestea, foloseste cea mai simpla abordare, care este doar separarea interogarilor de comenzi si utilizarea aceleiasi baze de date pentru ambele actiuni.

Esenta acestor tipare si punctul important aici este ca interogarile sunt idempotente: indiferent de cate ori interogati un sistem, starea sistemului respectiv nu se va schimba. Cu alte cuvinte, interogarile nu au efecte secundare.

Prin urmare, puteti utiliza un model de date diferit de „citire” decat modelul de domeniu „scrie” logica tranzactionala, chiar daca microserviciile de comanda utilizeaza aceeasi baza de date. Prin urmare, aceasta este o abordare simplificata CQRS.

Pe de alta parte, comenzile, care declanseaza tranzactii si actualizari de date, isi schimba starea in sistem. Cu comenzile, trebuie sa aveti grija atunci cand faceti fata complexitatii si regulilor de afaceri in continua schimbare. Aici doriti sa aplicati tehnici DDD pentru a avea un sistem mai bine modelat.

Modelele DDD prezentate in acest ghid nu ar trebui aplicate universal. Acestea introduc constrangeri asupra designului dumneavoastra. Aceste constrangeri ofera beneficii precum o calitate superioara in timp, in special in comenzi si alte coduri care modifica starea sistemului. Cu toate acestea, aceste constrangeri adauga complexitate cu mai putine beneficii pentru citirea si interogarea datelor.

Un astfel de model este modelul agregat, pe care il vom examina mai mult in sectiunile ulterioare. Pe scurt, in modelul Agregat, tratati multe obiecte de domeniu ca o singura unitate ca urmare a relatiei lor in domeniu. Este posibil sa nu obtineti intotdeauna avantaje din acest model in interogari; poate creste complexitatea logicii interogarilor. Pentru interogarile numai in citire, nu obtineti avantajele de a trata mai multe obiecte ca un singur Agregat. Obtineti doar complexitatea.

Asa cum se arata in Figura 7-2 din sectiunea anterioara, acest ghid sugereaza utilizarea tiparelor DDD numai in zona tranzactionala / actualizari a microserviciului dvs. (adica declansata de comenzi). Interogarile pot urma o abordare mai simpla si ar trebui separate de comenzi, urmand o abordare CQRS.

Pentru implementarea „laturii interogarilor”, puteti alege intre multe abordari, de la ORM-ul dvs. complet, cum ar fi EF Core, proiectii AutoMapper, proceduri stocate, vizualizari, vizualizari materializate sau un micro ORM.

In acest ghid si in eShopOnContainers (in special microserviciul de comanda) am ales sa implementam interogari directe folosind un micro ORM precum Dapper. Acest ghid va permite sa implementati orice interogare bazata pe instructiuni SQL pentru a obtine cele mai bune performante, datorita unui cadru usor, cu putine cheltuieli generale.

Cand utilizati aceasta abordare, orice actualizari ale modelului dvs. care afecteaza modul in care entitatile sunt persistente intr-o baza de date SQL necesita, de asemenea, actualizari separate la interogarile SQL utilizate de Dapper sau orice alte abordari separate (non-EF) pentru interogare.

Modelele CQRS si DDD nu sunt arhitecturi de nivel superior

Este important sa intelegem ca CQRS si majoritatea modelelor DDD (cum ar fi straturile DDD sau un model de domeniu cu agregate) nu sunt stiluri arhitecturale, ci doar modele arhitecturale. Microserviciile, SOA si arhitectura bazata pe evenimente (EDA) sunt exemple de stiluri arhitecturale. Acestea descriu un sistem de mai multe componente, cum ar fi multe microservicii. Modelele CQRS si DDD descriu ceva in interiorul unui singur sistem sau componenta; in acest caz, ceva in interiorul unui microserviciu.

Diferite contexte limitate (BC) vor folosi modele diferite. Au responsabilitati diferite si asta duce la solutii diferite. Merita subliniat faptul ca fortarea aceluiasi tipar peste tot duce la esec. Nu utilizati modele CQRS si DDD peste tot. Multe subsisteme, BC-uri sau microservicii sunt mai simple si pot fi implementate mai usor folosind servicii CRUD simple sau folosind o alta abordare.

Exista o singura arhitectura de aplicatie: arhitectura sistemului sau aplicatia end-to-end pe care o proiectati (de exemplu, arhitectura microserviciilor). Cu toate acestea, proiectarea fiecarui context limitat sau microserviciu din acea aplicatie reflecta propriile compromisuri si deciziile interne de proiectare la nivel de tipare de arhitectura. Nu incercati sa aplicati aceleasi modele arhitecturale ca CQRS sau DDD peste tot.

Resurse aditionale

• Martin Fowler. CQRS

  https://martinfowler.com/bliki/CQRS.html

• Greg Young. Documente CQRS

  https://cqrs.files.wordpress.com/2010/11/cqrs_documents.pdf

• Udi Dahan. CQRS clarificat

  https://udidahan.com/2009/12/09/clarified-cqrs/