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

Napiwek

Ta zawartość jest fragmentem książki eBook, architektury mikrousług platformy .NET dla konteneryzowanych aplikacji platformy .NET dostępnych na platformie .NET Docs lub jako bezpłatnego pliku PDF, który można odczytać w trybie offline.

Pobierz plik PDF

CQRS to wzorzec architektury, który oddziela modele do odczytywania i zapisywania danych. Powiązany termin Separacja zapytań poleceń (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 wycisza stan, ale nie oba. 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 ewoluowały system CQRS może implementować określanie źródła zdarzeń (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 baza danych odczytu jest zdenormalizowana, którą można dowiedzieć się w bardziej zaawansowanej literaturze 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.

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 danych (modele danych specjalnie utworzone dla aplikacji klienckich) na podstawie poleceń, modelu domeny i transakcji zgodnie ze wzorcem CQRS. Takie podejście zapewnia niezależne zapytania od ograniczeń i ograniczeń pochodzących z wzorców DDD, które mają sens tylko w przypadku transakcji i aktualizacji, zgodnie z wyjaśnieniem w kolejnych sekcjach.

Dodatkowe zasoby

• Greg Young. Przechowywanie wersji w systemie ze źródłem zdarzeń (Bezpłatny do czytania online e-book)
  https://leanpub.com/esversioning/read

PoprzedniNastępny