Naming Convention for Commands & Events

Question

Sto solo entrando in architetture event-driven e vorrei sapere qual è la convenzione per nominare comandi ed eventi. Lo so molto: i comandi dovrebbero essere nella forma DoSomething mentre gli eventi dovrebbero essere nella forma SomethingHappened. Quello di cui ho bisogno di chiarire è se ho bisogno di aggiungere la parola "Comando" ai miei comandi e "Evento" ai miei eventi, ad es. DoSomethingCommand invece di DoSomething e SomethingHappenedEvent rispetto a SomethingHappened. Vorrei anche sapere qual è la logica dietro la convenzione preferita dalla comunità. Grazie!

Answer 1

I suffissi Command e Event sono facoltativi e sono una questione di preferenza. Preferisco ometterli e cercare di rendere l'intento evidente solo dal nome. L'aspetto più importante dei comandi e degli eventi di denominazione è assicurarsi che riflettano il dominio aziendale più del dominio tecnico. Un sacco di volte termini come Crea, Aggiorna, Aggiungi, Cambia sono troppo tecnici e hanno meno significato nel dominio aziendale. Ad esempio, invece di dire UpdateCustomerAddress puoi dire RelocateCustomer che potrebbe avere un contesto aziendale più ampio.

Answer 2

La mia convenzione dipende dagli spazi dei nomi e con ciò intendo che non uso mai il suffisso Evento o Comando.

Inoltre, organizzo comandi ed eventi in spazi dei nomi separati in base al tipo di aggregazione che si intende influenzare.

Esempio:

// Commands 
MyApp.Messages.Commands.Customers.Create 
MyApp.Messages.Commands.Orders.Create 
MyApp.Messages.Commands.Orders.AddProduct 

// Events 
MyApp.Messages.Events.Customers.Created 
MyApp.Messages.Events.Orders.Created 
MyApp.Messages.Events.Orders.ProductAdded 

A seconda delle esigenze si potrebbe desiderare di inserire i vostri eventi in un assembly separato. La ragione di ciò sarebbe se fosse necessario distribuire eventi ai sistemi downstream. In questo caso probabilmente non vuoi che i sistemi downstream si preoccupino dei tuoi comandi (perché non dovrebbero).

Answer 3

Il comando di comando e l'evento sarebbero informazioni ridondanti se i vostri comandi/eventi sono correttamente denominati. Questo sarebbe rumore che rende il tuo codice meno leggibile. Ricorda la notazione ungherese? La maggior parte dei programmatori (che io sappia) non la usano più.

Answer 4

Comandi ed eventi formano una lingua per l'applicazione ... un'API. L'uso di termini come "comando" ed "evento" sono forse utili per le definizioni a livello di sistema in cui i termini tecnici sono significativamente combinati nello scopo di un'entità, ma se si hanno a che fare con definizioni di comportamento del dominio, quindi eliminare la terminologia tecnica/di sistema e favorire il business-speak. Renderà il tuo codice più leggibile e diminuirà la digitazione. Ho iniziato con le appendici 'Comando'/'Evento' ma ho realizzato che era una perdita di tempo e mi ha allontanato dall'Ubiquitous Language DDD reso popolare. HTH, Mike

Answer 5

La convenzione che ho visto molto e uso me stesso è che gli eventi devono essere in passato e descritto ciò che è accaduto:

• UserRegistered
• AccountActivated
• ReplyPosted

I comandi è qualcosa che ti piacerebbe fare.Quindi creare i nomi che illustrano che:

• CreateUser
• UppgradeUserAccount

Per quanto riguarda l'organizzazione, io di solito li metto insieme con l'aggregato radice che servono. Rende molto più facile vedere cosa è possibile fare e che tipo di eventi vengono generati.

Cioè, creo uno spazio dei nomi per ogni aggregato radice e metto tutto sotto (definizione del repository, eventi, comandi).

• MyApp.Core.Users
• MyApp.Core.Posts

ecc