Stosowanie metod CQRS i CQS w mikrousłudze DDD w eShopOnContainers

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

Projekt mikrousługi porządkowania w aplikacji referencyjnej eShopOnContainers jest oparty na zasadach CQRS. Jednak używa najprostszego podejścia, które po prostu oddziela zapytania od poleceń i używa tej samej bazy danych dla obu akcji.

Istotą tych wzorców i ważnym punktem jest to, że zapytania są idempotentne: bez względu na to, ile razy wykonujesz zapytanie o system, stan tego systemu nie ulegnie zmianie. Innymi słowy, zapytania są wolne od skutków ubocznych.

W związku z tym można użyć innego modelu danych "odczytuje" niż model domeny "zapis" logiki transakcyjnej, mimo że mikrousługi porządkowania używają tej samej bazy danych. W związku z tym jest to uproszczone podejście CQRS.

Z drugiej strony polecenia, które wyzwalają transakcje i aktualizacje danych, zmieniają stan w systemie. W przypadku poleceń należy zachować ostrożność podczas radzenia sobie ze złożonością i ciągle zmieniającymi się regułami biznesowymi. W tym miejscu chcesz zastosować techniki DDD w celu lepszego modelowania systemu.

Wzorce DDD przedstawione w tym przewodniku nie powinny być stosowane powszechnie. Wprowadzają one ograniczenia dotyczące projektu. Te ograniczenia zapewniają korzyści, takie jak wyższa jakość w czasie, zwłaszcza w poleceniach i innym kodzie, który modyfikuje stan systemu. Jednak te ograniczenia dodają złożoność z mniejszą liczbą korzyści związanych z odczytywaniem i wykonywaniem zapytań dotyczących danych.

Jednym z takich wzorców jest wzorzec agregacji, który analizujemy bardziej w kolejnych sekcjach. Krótko mówiąc, we wzorcu Agregacji wiele obiektów domeny jest traktowanych jako pojedyncza jednostka w wyniku ich relacji w domenie. Nie zawsze możesz uzyskać korzyści z tego wzorca w zapytaniach; może zwiększyć złożoność logiki zapytań. W przypadku zapytań tylko do odczytu nie uzyskujesz korzyści z traktowania wielu obiektów jako pojedynczej agregacji. Stopień złożoności można uzyskać tylko.

Jak pokazano na rysunku 7–2 w poprzedniej sekcji, ten przewodnik sugeruje używanie wzorców DDD tylko w obszarze transakcyjnym/aktualizacji mikrousługi (czyli zgodnie z poleceniami). Zapytania mogą być zgodne z prostszą metodą i powinny być oddzielone od poleceń, zgodnie z podejściem CQRS.

Aby zaimplementować "stronę zapytań", można wybrać między wieloma podejściami— od pełnego rozwiązania ORM, takiego jak EF Core, projekcje automapper, procedury składowane, widoki, zmaterializowane widoki lub mikro ORM.

W tym przewodniku i w eShopOnContainers (w szczególności mikrousługa zamawiania) wybraliśmy zaimplementowanie zapytań prostych przy użyciu mikro ORM, takiego jak Dapper. Ten przewodnik umożliwia zaimplementowanie dowolnego zapytania na podstawie instrukcji SQL w celu uzyskania najlepszej wydajności dzięki lekkiej strukturze z niewielkim obciążeniem.

W przypadku korzystania z tego podejścia wszelkie aktualizacje modelu, które mają wpływ na sposób utrwalania jednostek w bazie danych SQL, również wymagają oddzielnych aktualizacji zapytań SQL używanych przez program Dapper lub innych oddzielnych metod (innych niż EF) do wykonywania zapytań.

Wzorce CQRS i DDD nie są architekturami najwyższego poziomu

Ważne jest, aby zrozumieć, że wzorce CQRS i większość DDD (takich jak warstwy DDD lub model domeny z agregacjami) nie są stylami architektury, ale tylko wzorcami architektury. Mikrousługi, SOA i architektura sterowana zdarzeniami (EDA) to przykłady stylów architektury. Opisują system wielu składników, takich jak wiele mikrousług. Wzorce CQRS i DDD opisują coś wewnątrz jednego systemu lub składnika; w tym przypadku coś wewnątrz mikrousługi.

Różne powiązane konteksty (BCs) będą używać różnych wzorców. Mają różne obowiązki i prowadzi to do różnych rozwiązań. Warto podkreślić, że wymuszanie tego samego wzorca wszędzie prowadzi do awarii. Nie używaj wzorców CQRS i DDD wszędzie. Wiele podsystemów, kontrolerów BCs lub mikrousług jest prostszych i można je łatwiej zaimplementować przy użyciu prostych usług CRUD lub innego podejścia.

Istnieje tylko jedna architektura aplikacji: architektura systemu lub kompleksowej aplikacji, którą projektujesz (na przykład architektura mikrousług). Jednak projekt każdego kontekstu ograniczonego lub mikrousługi w ramach tej aplikacji odzwierciedla własne kompromisy i wewnętrzne decyzje projektowe na poziomie wzorców architektury. Nie należy próbować stosować tych samych wzorców architektury co CQRS lub DDD wszędzie.

Dodatkowe zasoby

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

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

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

PoprzedniNastępny