Czy podczas korzystania z DDD i CRQS powinno być dokładnie jedno zdarzenie na polecenie?

Szukam sposobu zaprojektowania aplikacji ddd z konwencją nad konfiguracją.

Powiedz, że zagregowany „Klient” ma zdefiniowaną komendę „FillProfile”. Logicznie wywoła zdarzenie „ProfileFilled”.

Czy zdarzają się przypadki, gdy polecenie wywoła więcej niż zdarzenie lub gdy polecenie wywoła inne zdarzenia w oparciu o jakąś logikę? Czy jest to zawsze relacja 1 - 1 (1 komenda zawsze nie zgłosi żadnego lub pojedynczego zdarzenia danego typu).

Proszę o to, ponieważ jeśli jest to fakt, że polecenie zawsze wywoła to samo zdarzenie, mogę na tym fakcie zbudować system konwencji. Wiem, że „RaiseEvent” spowoduje „EventRaised” ...

Ponieważ otagowałeś swoje pytanie słowem „CQRS”, myślę, że masz na myśli zdarzenia w kontekście „CQRS i pozyskiwania zdarzeń”, tak jak to opisano tutaj . W tym samouczku dobrze wyjaśniono różnicę między zdarzeniami a poleceniami:

• zdarzenia wychwytują elementarne „rzeczy, które mogą się zdarzyć” w twoim systemie, z punktu widzenia systemu.

• polecenia są definiowane przez to, co użytkownik uważa za operację, z jego punktu widzenia

I chociaż często prowadzi to do kilku poleceń i zdarzeń w korespondencji 1: 1, te różne punkty widzenia mogą prowadzić do poleceń, które uruchamiają więcej niż jedno zdarzenie, lub różnych zdarzeń w zależności od parametrów polecenia. Mogę sobie nawet wyobrazić przypadki, w których polecenie w ogóle nie wywołuje zdarzenia, ale byłby to bardzo wyjątkowy przypadek, niezbyt typowy.

Na przykład samouczek wspomina o zdarzeniach

• TabOpened
• Napoje Zamówione
• FoodOrders

i polecenia

• OpenTab
• Złożyć zamówienie

Tutaj polecenie „OpenTab” doprowadzi do zdarzenia „TabOpened”, ale polecenie PlaceOrder doprowadzi do zdarzeń „DrinksOrders”, „FoodOrders” lub obu.

W rzeczywistości, jeśli projektujesz nowy system „od zera”, możesz spróbować zaprojektować go za pomocą korespondencji 1: 1 między poleceniami i zdarzeniami i sprawdzić, jak dobrze to się skaluje, gdy system staje się większy. Możesz nawet wypróbować podejście hybrydowe: listę zdarzeń i poleceń z korespondencją 1: 1 wraz z kilkoma dodatkowymi połączonymi poleceniami. Po prostu spróbuj, jak daleko cię to zaprowadzi w konkretnym projektowanym systemie.

Zwykle jedno polecenie prowadzi do jednego zdarzenia. Ale w niektórych przypadkach może to być więcej niż jeden, zależy to od implementacji.

Albo twoje polecenie wywołuje inne polecenia i każde z nich uruchamia własne zdarzenia. Albo twoje polecenie samodzielnie wykonuje różne zadania i wydaje wiele zdarzeń. Na przykład:

RegisterUserCommand

• User.create (adres e-mail, hasło) → UserCreatedEvent
• User.updateProfile (firstName, lastName, location) → UserProfileUpdatedEvent
• User.joinDefaultGroup () → UserJoinedGroupEvent

Jedno polecenie może wywołać wiele zdarzeń. Jest to po prostu logiczne zakończenie jednego faktu: Composite commandistnieje.

Powiedzmy, że masz dwie komendy, z których każda wywołuje zdarzenie. Następnie utwórz złożone polecenie tych dwóch. Z punktu widzenia jednego używającego polecenia złożonego wydaje się, że polecenie wywołało dwa zdarzenia.

Nic więc nie stoi na przeszkodzie, aby jedno polecenie wywoływało wiele (a nawet nie) zdarzeń.