CQRS bez Event Sourcing-jakie są wady?

Całkowicie zgadzam się z Dennisem, ES nie jest warunkiem wstępnym dla CQRS, w rzeczywistości CQRS sam w sobie jest dość łatwy do wdrożenia i ma potencjał, aby naprawdę uprościć swój projekt.

Możesz znaleźć płynne wprowadzenie do niego tutaj

Po drugie jakie korzyści przynosi samo CQRS ?

• upraszcza obiekty domeny, wysysając wszystkie pytania
• umożliwia skalowanie kodu, Twoje zapytania są oddzielone i mogą być tuningowane łatwo
• jak iterować projekt produktu można dodać/usunąć/zmienić poszczególnych poleceń/zapytań, zamiast zajmować się większymi struktury jako całość (np. byty, Agregaty, Moduły).
• polecenia i zapytania tworzą dobrze znane słownictwo, z którym można rozmawiać specjaliści od domen. Inne wzory architektoniczne (np. rury i filtry, aktorów) posługują się terminami i pojęciami, które mogą być trudniejsze do uchwycenia przez nie-programistów.
• ogranicza użycie ORM (jeśli używasz jednego), czuję ORM ' s bring in nieuzasadniona złożoność, jeśli spróbujesz użyć ich do zapytań, abstrakcje są nieszczelne i ciężkie, próba ich dostrojenia to nocna klacz :) Używanie ORM tylko po stronie poleceń sprawia, że wiele łatwiejszy, zwykły stary SQL jest najlepszy dla zapytań, prawdopodobnie za pomocą prosta biblioteka do konwersji zestawów wyników na DTO jest najbardziej potrzebna.

Więcej o tym, jak projekt korzyści CQRS można znaleźć tutaj

Nie zapominaj również o niematerialnych korzyściach z CQRS

Jeśli nadal masz wątpliwości, możesz chcieć przeczytać to

Obecnie używamy CQR dla projektów o średniej złożoności i uznaliśmy, że jest bardzo odpowiedni. Zaczęliśmy używać niestandardowego kodu bootstrap , a teraz przeszliśmy do używania Axon Framework , Aby udostępnić nam niektóre komponenty infrastruktury

Zapraszam do mnie, jeśli chcesz wiedzieć coś bardziej szczegółowego.

Istnieje podstawowy problem wzorca Event Sourcing, czyli zdarzenia w sklepie Event Store mogą nie być kompatybilne z procesorami obsługi zdarzeń w Twojej aplikacji z powodu zmiany kodu.

To powiedziawszy, za każdym razem, gdy modyfikujesz obsługę zdarzeń poprzez dodawanie nowych funkcji, musisz pomyśleć o wstecznej kompatybilności. Musisz upewnić się, że Twój kod zawsze może obsłużyć to samo zdarzenie w innym etapie utworzonym przez inną wersję kodu.

Kiedy twój aplikacja staje się bardziej złożona, znajdziesz to naprawdę wrzód na tyłku, aby była kompatybilna wstecz.

Myślę, że Event Sourcing jest tym, co sprawia, że ludzie boją się CQRS. Nie bez powodu. To nie jest naturalne - kiedy wchodzi się w interakcję z czymś w prawdziwym świecie, nie musisz mieć całej historii o tym obiekcie.

"event sourcing jest całkowicie ortogonalną koncepcją CQRS" (source ) - technicznie jeśli nie używasz ES nie tracisz nic z funkcji CQRS.

Nie mam pojęcia, dlaczego Event Sourcing jest uważany za jedyną podstawę do rozwiązania niektórych problemy związane z "komunikacją", takie jak: powielanie/Brak wiadomości, Zmiana kolejności wiadomości i kolizje danych itp. Nie jest prawdą, że jeśli nie korzystasz z Event Sourcing, nie możesz stworzyć kapsułkowanych środków, aby rozwiązać takie problemy w inny sposób.

Jak widzę alternatywne sposoby implementacji komunikatów CQRS za pomocą kolejna zasada organizacji danychmożesz przeczytać tutaj.

Proponuję podejście "podpisane dokumenty", w którym traktujesz swoje dane nie jako kompozycję modyfikacji zdarzenia, ale jako skład niezmiennych części podpisanych przez odpowiedzialnych użytkowników. Jestem pewien, że może być wiele innych rozwiązań do realizacji przepływu wiadomości i przechowywania danych. Musisz wziąć pod uwagę swój model biznesowy przy wyborze, z którego chcesz korzystać.

Moim zdaniem popełniasz duży błąd, nie używając event sourcingu z CQRS.

Po pierwsze, prawie na pewno będziesz miał problemy z synchronizacją modelu zapytania z Modelem polecenia. W przypadku magazynu zdarzeń, jeśli strona zapytania kiedykolwiek wyjdzie z synchronizacji, wystarczy odtworzyć zdarzenia, aby je poprawić. Taka jest teoria!

Ale z Event Sourcing, można również uzyskać do przechowywania pełnej historii wszystkich transakcji entity. A to oznacza, że możesz zdecydować się na utworzenie nowego zapytania i widoki po wdrożeniu. Są to bardzo często widoki, które nie byłyby możliwe w przypadku CQR bez zdarzeń. Słyszałem, że Greg Young podał przykład sprawdzania przedmiotów, które zostały dodane, a następnie usunięte z koszyka. Dzięki Event Sourcing jest to możliwe. Bez ES nie jest to możliwe, ponieważ przechowujesz tylko ostateczny stan koszyka.

CQRS istnieje z powodu pozyskiwania zdarzeń, tak powiedział jego ojciec . Jeśli możesz sobie pozwolić na pozyskiwanie wydarzeń, powinieneś to zrobić. Zaimplementowałem proste podejście SQL Server oparte na Microsoft CQRS Journey.