Udostępnij za pośrednictwem

Stosowanie uproszczonych wzorców CQRS i DDD w mikrousłudze

Wskazówka

Ta treść jest fragmentem eBooka "Architektura mikrousług .NET dla konteneryzowanych aplikacji .NET", dostępnego na .NET Docs lub jako bezpłatny plik PDF do pobrania i czytania w trybie offline.

Pobierz plik PDF

Miniatura okładki eBooka „Architektura mikrousług platformy .NET dla konteneryzowanych aplikacji platformy .NET”.

CQRS to wzorzec architektury, który oddziela modele do odczytywania i zapisywania danych. Powiązany termin Command Query Separation (CQS) został pierwotnie zdefiniowany przez Bertrand Meyer w swojej książce Object-Oriented Software Construction. Podstawową ideą jest to, że operacje systemu można podzielić na dwie ostro oddzielone kategorie:

  • Kwerendy. Te zapytania zwracają wynik i nie zmieniają stanu systemu i nie są wolne od skutków ubocznych.

  • Polecenia. Te polecenia zmieniają stan systemu.

CQS to prosta koncepcja: chodzi o metody w tym samym obiekcie, które są zapytaniami lub poleceniami. Każda metoda zwraca stan lub modyfikuje stan, ale nie oba jednocześnie. Nawet pojedynczy obiekt wzorca repozytorium może być zgodny z CQS. CQS można uznać za podstawową zasadę CQRS.

Podział odpowiedzialności poleceń i zapytań (CQRS) został wprowadzony przez Grega Younga i zdecydowanie promowany przez Udi Dahan i innych. Jest ona oparta na zasadzie CQS, chociaż jest bardziej szczegółowa. Można go uznać za wzorzec oparty na poleceniach i zdarzeniach oraz opcjonalnie na komunikatach asynchronicznych. W wielu przypadkach usługa CQRS jest związana z bardziej zaawansowanymi scenariuszami, takimi jak posiadanie innej fizycznej bazy danych do odczytu (zapytań) niż w przypadku zapisów (aktualizacji). Ponadto bardziej rozwinięty system CQRS może implementować Event-Sourcing (ES) dla bazy danych aktualizacji, więc można przechowywać tylko zdarzenia w modelu domeny zamiast przechowywać dane bieżącego stanu. Jednak to podejście nie jest używane w tym przewodniku. W tym przewodniku jest używane najprostsze podejście CQRS, które składa się tylko z oddzielenia zapytań od poleceń.

Aspekt separacji CQRS jest osiągany przez grupowanie operacji zapytań w jednej warstwie i poleceniach w innej warstwie. Każda warstwa ma własny model danych (należy pamiętać, że mówimy, że model, niekoniecznie inna baza danych) i jest tworzony przy użyciu własnej kombinacji wzorców i technologii. Co ważniejsze, dwie warstwy mogą znajdować się w tej samej warstwie lub mikrousłudze, co w przykładzie (zamawianie mikrousługi) używanej w tym przewodniku. Można je też zaimplementować w różnych mikrousługach lub procesach, aby można je było zoptymalizować i skalować w poziomie oddzielnie bez wpływu na siebie.

CQRS oznacza posiadanie dwóch obiektów dla operacji odczytu/zapisu, gdzie w innych kontekstach jest jeden. Istnieją powody, dla których warto mieć zdenormalizowaną bazę danych odczytów, o których można się dowiedzieć z bardziej zaawansowanej literatury CQRS. Jednak nie używamy tutaj tego podejścia, w którym celem jest zwiększenie elastyczności zapytań zamiast ograniczania zapytań z ograniczeniami z wzorców DDD, takich jak agregacje.

Przykładem tej usługi jest zamawianie mikrousługi z aplikacji referencyjnej eShopOnContainers. Ta usługa implementuje mikrousługę opartą na uproszczonym podejściu CQRS. Używa pojedynczego źródła danych lub bazy danych, ale dwa modele logiczne oraz wzorce DDD dla domeny transakcyjnej, jak pokazano na rysunku 7-2.

Diagram przedstawiający mikrousługę CQRS i DDD na wysokim poziomie w uproszczonej formie.

Rysunek 7–2 Uproszczona mikrousługa oparta na języku CQRS i DDD

Mikrousługa logiczna "Ordering" zawiera bazę danych Ordering, która może być, ale nie musi być tym samym hostem platformy Docker. Posiadanie bazy danych na tym samym hoście platformy Docker jest dobre do programowania, ale nie w środowisku produkcyjnym.

Warstwa aplikacji może być samym internetowym interfejsem API. Ważnym aspektem projektowania jest to, że mikrousługa podzieliła zapytania i modele widoków (modele danych specjalnie utworzone dla aplikacji klienckich) od poleceń, modelu domeny i transakcji zgodnie ze wzorcem CQRS. Takie podejście zapewnia niezależne zapytania od ograniczeń i restrykcji pochodzących z wzorców DDD, które mają sens tylko w przypadku transakcji i aktualizacji, jak to wyjaśniono w kolejnych sekcjach.

Dodatkowe zasoby

PoprzedniNastępny