Komunikacja międzygregatowa w CQRS + DDD + zaopatrywanie w wydarzenia

Question

W jaki sposób należy oddzielić aggregate roots (AR) od siebie nawzajem w środowisku zbudowanym na zasadach DDD, wykorzystując zagregowany back-end zdarzeń?

Na przykład mam agregat root (AR) Facility, który ma fabryczną metodę odpowiedzialną za tworzenie AR Booking AR. Booking jest zależną od czasu kombinacją Person AR i Facility AR. Numer Person można zarezerwować tylko w jednym numerze Facility.

W DDD zawierałabym odniesienia do Booking w Person i Person w Facility. Jednak przy generowaniu zdarzeń do wykorzystania w pozyskiwaniu zdarzeń myślę, że próba obsługi deserializacji zdarzeń z zaplecza stanie się zbyt duża. Dlatego zacząłem jedynie utrzymywać odniesienia do unikalnych id opartych na wartości obiektu. Pojawia się jednak nowy problem, gdy metoda na AR musi wywołać inną metodę na innym AR - jak sobie z tym poradzisz? Hit repozytorium źródła zdarzeń z domeny AR?

Jaki jest ogólny przypadek użycia w tym scenariuszu? Czy podchodzę do tego źle?

Answer 1

Zagregowane granice korzeni definiują granicę konsystencji. Wewnątrz kruszywa gwarantowana jest spójność. Na zewnątrz ... nie jest. Więc nie powinieneś mieć operacji, które obejmują kilka agregatów i muszą być spójne. Jeśli potrzebujesz transakcji obejmującej dwa agregaty, powinieneś sprawdzić swoje zagregowane granice.

Dla rzeczy, które mają miejsce poza agregatem, powinieneś mieć program obsługi zdarzeń, który wyśle ​​polecenie do innych agregacji. Jeśli logika działań między agregatami jest bardziej skomplikowana, można zdefiniować proces, automat stanów, który będzie nasłuchiwać zdarzeń i wysyłać polecenia do agregatów. Procesy mogą być używane do definiowania długich transakcji (z kompensacją zamiast wycofywania) lub podejmowania decyzji biznesowych w oparciu o to, co dzieje się w systemie na dużą skalę (nawet między ograniczonymi kontekstami).

Answer 2

Podczas korzystania z Event Sourcing i CQRS najbardziej eleganckim (przynajmniej moim zdaniem) sposobem komunikacji między AR jest przesyłanie wiadomości. Możesz spojrzeć na projekt Ncqrs (będzie łatwiej, jeśli jesteś facetem .NET), szczególnie gałąź "Wiadomości". Chodzi o to, że ARs implementuje interfejs IMessageHandler dla każdego obsługiwanego typu wiadomości, a klasa bazowa AR udostępnia metodę Wyślij do wysyłania wiadomości. Za pomocą tego API klienci mogą wywoływać zachowanie modelu, a sam model może się komunikować (między AR).