Quando si utilizzano DDD e CRQS, dovrebbe essere esattamente un evento per comando?

Sto cercando un modo per progettare un'applicazione ddd con convenzione sulla configurazione.

Supponiamo che un "client" aggregato abbia un comando definito "FillProfile". Logicamente genererà un evento "ProfileFilled".

Ci sono casi in cui un comando genererà più di un evento o in cui un comando genererà eventi diversi in base a una logica? O è sempre una relazione 1 - 1 (1 comando genererà sempre nessuno o un singolo evento di un determinato tipo).

Lo sto chiedendo perché se questo è un fatto, un comando genererà sempre lo stesso evento, posso costruire il mio sistema di convenzione su quel fatto. So che "RaiseEvent" si tradurrà in "EventRaised" ...

Dal momento che hai taggato la tua domanda con "CQRS", immagino che intendi eventi in un contesto "CQRS & Event Sourcing", come è descritto qui . In questo tutorial , la differenza tra eventi e comandi è ben spiegata:

• gli eventi catturano le "cose ​​che possono accadere" elementari nel tuo sistema, dal punto di vista del sistema.

• i comandi sono definiti da ciò che l'utente considera un'operazione, dal suo punto di vista

E sebbene ciò porti spesso a un paio di comandi ed eventi con una corrispondenza 1: 1, questi diversi punti di vista possono portare a comandi che generano più di un evento o eventi diversi a seconda dei parametri del comando. Posso persino immaginare casi in cui un comando non genera affatto un evento, ma sarebbe un caso eccezionale, non molto tipico.

Ad esempio, il tutorial menziona eventi

• TabOpened
• DrinksOrdered
• FoodOrdered

e comandi

• OpenTab
• Invia ordine

Qui, il comando "OpenTab" porterà a un evento "TabOpened", ma il comando PlaceOrder porterà agli eventi "DrinksOrdered", "FoodOrdered" o entrambi.

In effetti, se stai progettando un nuovo sistema "da zero", puoi provare a progettarlo con una corrispondenza 1: 1 tra comandi ed eventi e osservare quanto si ridimensiona quando il sistema diventa più grande. Puoi anche provare un approccio ibrido: un elenco di eventi e comandi con una corrispondenza 1: 1, insieme ad alcuni comandi combinati aggiuntivi. Prova quanto lontano ti porta per quel particolare sistema che stai progettando.

Di solito un comando porterà a un evento. Ma in alcuni casi può anche essere più di uno, dipende dalla tua implementazione.

O il tuo comando chiama altri comandi e ognuno di essi genera i propri eventi. Oppure il tuo comando esegue diverse attività da solo e genera più eventi. Per esempio:

RegisterUserCommand

• User.create (email, password) → UserCreatedEvent
• User.updateProfile (firstName, lastName, location) → UserProfileUpdatedEvent
• User.joinDefaultGroup () → UserJoinedGroupEvent

Un comando può generare più eventi. È semplicemente la logica conclusione di un fatto: Composite commandesiste.

Diciamo che hai due comandi, ognuno che genera un evento. Quindi, si crea un comando composito di quei due. Dal punto di vista di uno che utilizza il comando composito, sembra che il comando abbia generato due eventi.

Quindi non c'è nulla che ti impedisce di avere un singolo comando che genera più (o addirittura no) eventi.