2015-07-16 16 views
8

Jestem nowy w świecie CQRS/ES i mam pytanie. Pracuję nad aplikacją internetową do fakturowania, która wykorzystuje źródła zdarzeń i CQRS.Agregatory CQRS

Moje pytanie brzmi następująco: nowe polecenie wchodzące do systemu (powiedzmy ChangeLineItemPrice) powinno przechodzić przez model domeny, aby można było go sprawdzić jako prawną komendę (na przykład, aby sprawdzić, czy ten element zamówienia faktycznie istnieje, cena nie narusza żadnych reguł biznesowych itp.). Jeśli wszystko pójdzie dobrze (polecenie nie zostanie odrzucone) - wtedy odpowiednie zdarzenie zostanie utworzone i zapisane (na przykład LineItemPriceChanged)

Rzeczą, której nie zrozumiałem, jest to, jak zachować ten zbiór w pamięci na samym początku, przed próbą zastosowania polecenia. Jeśli mam milion faktur w systemie, czy powinienem odtwarzać całą historię za każdym razem, gdy chcę zastosować polecenie? Czy zawsze zapisuję zdarzenie bez walidacji i sprawdzam poprawności podczas konstruowania modeli/rzutów widoku?

Jeśli źle zrozumiałem każdą część procesu, byłbym wdzięczny za informację zwrotną.

Dzięki za pomoc!

Odpowiedz

19

Nie jesteś sam, to powszechne nieporozumienie. Pozwól mi najpierw odpowiedzieć na część walidacyjną:

Istnieją dwa rodzaje walidacji, które mają miejsce w tego rodzaju systemie. Pierwszy to rodzaj, w którym szukasz prawidłowych adresów e-mail, tylko numerycznych lub wymaganych pól. Ten typ jest wykonywany przed wydaniem polecenia. Polecenie, które zawiera tego rodzaju problemy, nie powinno być zgłaszane jako polecenia (w przypadku paska i szelek można sprawdzić po stronie domeny, ale nie jest to problem w domenie i lepiej jest po prostu zapobiec temu scenariuszowi).

Następnym typem sprawdzania poprawności jest pod adresem. Może to być rzecz, o której wspomniałeś, gdy sprawdzasz ceny w zestawie określonych parametrów. Jest to pojęcie domeny, które ludzie biznesu rozumieją, robią i umieją wyrazić.

Następna faza polega na tym, aby domena zastosowała zmianę stanu i podniosła powiązane zdarzenia. Są one następnie utrzymywane i sukcesy publikowane dla pozostałej części aplikacji.

Wszystko to można zrobić z zagregowaną pamięcią. Działania są skoordynowane z usługą domeny, która obsługuje polecenie. Ładuje agregat, aplikuje wszystkie przeszłe zdarzenia (lub ładuje migawkę), a następnie wydaje polecenie. Po pomyślnym wykonaniu polecenia żąda wszystkich nowych niezatwierdzonych zdarzeń i próbuje je utrzymać. Po sukcesie publikuje nowe wydarzenia.

Jak widać ładuje tylko zdarzenia dla tego konkretnego agregatu. Nawet przy wielu wydarzeniach proces ten przebiega błyskawicznie. Jeśli wydajność jest problemem, istnieją strategie, takie jak utrzymywanie agregacji pamięci lub migawki, które można zastosować.

Do ostatniego punktu dotyczącego sprawdzania poprawności zdarzeń. Ponieważ mogą być generowane tylko przez twój agregat, są godne zaufania.

Jeśli chcesz bardziej szczegółowo sprawdzić moje przegląd CQRS i ES here. I spójrz na mój post o tym, jak budować zagregowane korzenie here.

Powodzenia - mam nadzieję, że pomogą!

+0

Dzięki, to bardzo pomaga! – amitayh

+0

Świetnie. Czy to wystarczająco dobre, aby zostać oznaczonym jako odpowiedź? szturchać.. – Codescribler

0

Dobrze, że trzeba powtórzyć wydarzenie, aby "nawodnić" agregat domeny. Ale nie musisz odtwarzać wszystkich zdarzeń dla wszystkich faktur.Jeśli przechowujesz identyfikator obiektu głównego agregatu w zdarzeniach, możesz po prostu wybrać i odtworzyć zdarzenia z odpowiednim identyfikatorem.

Następnie, w jaki sposób znaleźć odpowiedni zagregowany identyfikator roota? Jeden z repozytoriów do odczytu powinien zawierać odpowiednie informacje, aby uzyskać identyfikator, na podstawie zestawu kryteriów wyszukiwania.

Powiązane problemy