Udostępnij za pośrednictwem

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

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”.

Projekt mikrousługi zamówień 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 domenowy logiki transakcyjnej "zapisuje", mimo że mikrousługi odpowiedzialne za realizację zamówień 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. Uzyskujesz tylko złożoność.

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ą stosować prostsze podejście i powinny być oddzielone od poleceń, zgodnie z podejściem CQRS.

Aby zaimplementować "stronę zapytań", można wybierać spośród wielu metod — przy użyciu pełnoprawnego ORM, takiego jak EF Core, projekcji AutoMapper, procedur składowanych, widoków, zmaterializowanych widoków czy 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

PoprzedniNastępny