CQRS - jak modelować system wykonywania scenariuszy

Question

Niedawno zacząłem badać CQRS i DDD dla projektu zielonego pola, który mam zamiar rozpocząć. Uczyłem się wielu materiałów od Udi Dahana, Grega Younga, Marka Nijhofa i innych. Były naprawdę bardzo pomocne i myślę, że dobrze rozumiem te pojęcia. Ale wciąż mam pewne pytania dotyczące tego, w jaki sposób mogę je zastosować w mojej własnej domenie.

Mój system będzie zasadniczo złożonym mechanizmem reguł - w którym reguły będą dyktować ostateczną cenę niektórych produktów. Definicje produktów i reguły zostaną wprowadzone do systemu przez administratorów. Reguły zostaną zaprojektowane przez administratorów przy użyciu predefiniowanego zestawu właściwości, które mogą mieć wartości z predefiniowanego zestawu, na przykład "Cel zakupu" (odsprzedawanie, wypożyczanie) lub bezpłatne wartości formularzy, takie jak wiek.

Każdy produkt będzie miał cenę bazową, a zasady będą w zasadzie dodawane/usuwane z ceny podstawowej, jeśli będą miały zastosowanie.

Bardzo prosta zasada próbka może być:

o produkt X, IF (Zakup Cel = odsprzedaży i wiek> 25) Dodać 25 $ do ceny podstawowej.

Istnieją zatem dwa rodzaje użytkowników, którzy korzystają z systemu, administratorzy, którzy definiują produkty, zasady i ceny bazowe; oraz inni użytkownicy, którzy wyszukują ceny w oparciu o scenariusz, w który wchodzą za pośrednictwem interfejsu użytkownika "co-jeśli".

Moje zamieszanie jest następujące: uruchomienie scenariusza wcale nie zmienia stanu domeny, żaden inny system zewnętrzny/osoba nie jest zainteresowany wynikiem wykonania scenariusza, ale sam użytkownik uruchamiający - zwraca wynik kalkulacji ceny po uruchomieniu odpowiednich reguł dla danego scenariusza. Na przykład użytkownik może wybrać opcję Produkt X i zapytać o cenę dla danego scenariusza, na przykład (Zakup celu = Odsprzedaż i Wiek = 40). Ponownie, ponieważ ta operacja nie zmienia wcale stanu domeny, domyślam się, że jest to zapytanie. Ale na scenariuszu działa mechanizm reguł, który pozwala obliczyć ostateczną cenę, którą, jak sądzę, można zaklasyfikować jako działającą logikę domeny. Więc - gdzie ta logika należy? Czy jest to kwerenda, która działa po prostu poza modelem odczytu, czy uruchamia scenariusz polecenie, które musi zostać uruchomione w modelu domeny? Ponownie, wydaje się, że warstwa domeny jest miejscem dla tych reguł, ale jak mogę przekazać wynik wykonania scenariusza użytkownikowi (czuje się jak zapytanie o to myślenie w ten sposób). A może CQRS nie jest właściwym rozwiązaniem dla tego konkretnego problemu?

Answer 1

Miałem ten dokładny problem w mojej własnej domenie (e-planowanie 4 opieki zdrowotnej). Zasadniczo system jest skonfigurowany przy użyciu modelu domeny (strona zapisu). Będzie to definiowanie reguł, produktów i cen bazowych w Twojej domenie. Co wychodzi z domeny? Wydarzenia, zmiany stanu, rzeczy, które się wydarzyły wraz z przyczynami. Teraz to, co zrobiłem, pochłonęło te wydarzenia w innym kontekstie, w moim przypadku złożoną wyszukiwarkę, która znajduje wolne miejsca w harmonogramach lekarzy, sal operacyjnych i drogiego sprzętu. Może to być również trasa, którą możesz wziąć, pochłaniając produkt, cenę bazową i zdarzenia związane z regułą, i przechowywać je w taki sposób, aby mechanizm reguł, znajdujący się nad tymi danymi, mógł obsłużyć żądania użytkowników dotyczące scenariuszy tak skutecznie, jak możliwy. Najprawdopodobniej dowiesz się, że model do przechowywania zmian (domeny) różni się od modelu zoptymalizowanego pod kątem zapytań o scenariusze "co jeśli" (silnik reguł). Twoja domena będzie prawdopodobnie zawierała reguły takie jak "nie możesz podać tego samego produktu dwa razy" lub "ta zasada nigdy nie zostanie dopasowana (wiek & wiek> 25)". Domena zajmuje się tylko dopuszczeniem prawidłowych zmian stanu. Nie dotyczy to silnika reguł. Skłoni Cię do ponownego użycia pojęć/klas w silniku reguł zdefiniowanych w domenie. Oprzyj się temu pragnieniu.Pytanie, czy rzeczywiście służą temu samemu celowi. Modelowanie go dwa razy w innym celu nie jest brudne ani narusza DRY.

Answer 2

CQRS nic nie mówi o tym, że nie powinna być logika domeny w części zapytania aplikacji. Jeśli jest to możliwe i praktyczne, dobrze jest mieć oddzielne zdenormalizowane magazyny zapytań dla każdego aspektu lub nawet zapytania o aplikację, ale oczywiście nie jest to konieczne.

Krótko mówiąc, zapytanie to zapytanie, niezależnie od tego, jak skomplikowane jest zadanie znalezienia odpowiedzi.