2012-09-20 38 views
10

Estoy accediendo a arquitecturas basadas en eventos y me gustaría saber cuál es la convención para nombrar comandos y eventos. Sé mucho de esto: los comandos deben tener la forma DoSomething mientras que los eventos deben tener el formato SomethingHappened. Lo que necesito aclarar es si necesito agregar la palabra 'Comando' a mis comandos y 'Evento' a mis eventos, por ej. DoSomethingCommand en comparación con solo DoSomething y SomethingHappenedEvent en lugar de simplemente SomethingHappened. También me gustaría saber cuál es el fundamento detrás de la convención preferida por la comunidad. ¡Gracias!Convención de nombres para comandos y eventos

+0

Gracias! Solo lo hice. Tardó un poco en descubrir cómo hacerlo. – Tolu

Respuesta

12

Los sufijos Command y Event son opcionales y son una cuestión de preferencia. Prefiero omitirlos y tratar de hacer que el intento sea evidente solo por el nombre. El aspecto más importante de nombrar comandos y eventos es asegurarse de que reflejen el dominio comercial más que el dominio técnico. Muchas veces, términos como Crear, Actualizar, Agregar, Cambiar son demasiado técnicos y tienen menos significado en el dominio comercial. Por ejemplo, en lugar de decir UpdateCustomerAddress, puede decir RelocateCustomer que podría tener un contexto comercial más amplio.

+0

Gracias, comencé a implementar el uso de este enfoque. También me gusta el punto de @MikaelÖstberg sobre el uso de espacios de nombres. Sin embargo, un punto menor que noté fue el hecho de que el Evento/Comando anexado parecía leer mejor al crear el objeto. Comparar: 'userSignedOut var = new UserSignedOut() {};' ' bus.Publish (userSignedOut);' con 'userSignedOutEvent var = new UserSignedOutEvent() {};' ' bus.Publish (userSignedOutEvent); ' – Tolu

8

Mi convención depende de los espacios de nombres y me refiero a que nunca uso el sufijo Evento ni Comando.

También organizo comandos y eventos en espacios de nombres separados basados ​​en el tipo agregado que están destinados a afectar.

Ejemplo:

// 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 

Dependiendo de sus requisitos es posible que desee colocar sus eventos en un ensamblado independiente. La razón de esto sería si necesita distribuir eventos a sistemas posteriores. En ese caso, probablemente no desee que los sistemas posteriores tengan que preocuparse por sus comandos (porque no deberían).

+0

Muchas gracias, @mikael. Esto tiene mucho sentido y es la dirección en la que me inclino actualmente. Solo quería aclarar cuál es la práctica estándar. – Tolu

+0

No diría que es una práctica estándar. Esta es solo la forma en que lo hago. Sin embargo, creo que esto sigue a las convenciones .Net que hacen uso de espacios de nombres como parte del nombre completo y no se repiten con sufijos y otras cosas. El único inconveniente es que Resharper ofrece un montón de opciones cuando desea agregar una declaración de uso para uno de los 20 eventos algo llamado 'Creado'. –

+0

Tiendo a separar mis comandos y eventos en ensamblajes separados y uso diferentes espacios de nombres como @ MikaelÖstberg descrito anteriormente. Tampoco recomendaría atacar Comando o Evento al final de esos mensajes. +1 –

3

Agregar Comando y Evento sería información redundante si sus comandos/eventos son nombrados correctamente. Esto sería un ruido que hace que tu código sea menos legible. ¿Recuerdas la notación húngara? La mayoría de los programadores (que yo sepa) ya no lo usan.

3

Los comandos y eventos forman un idioma para su aplicación ... una API. El uso de términos como 'comando' y 'evento' quizás sean útiles para definiciones de nivel de sistema donde los términos técnicos se mezclan de manera significativa en el propósito de una entidad, pero si se trata de definiciones de comportamiento del Dominio, entonces descarte la terminología técnica/del sistema y favorecer el habla de negocios. Hará que su código se lea de forma más natural y disminuirá el tipeo. Empecé con los apéndices 'Comando'/'Evento' pero me di cuenta de que era una pérdida de tiempo y me alejaba del popular lenguaje DDD ubicuo. HTH, Mike

1

La convención que he visto mucho y yo utilizo es que los eventos deben estar en tiempo pasado y descrito lo que sucedió:

  • UserRegistered
  • AccountActivated
  • ReplyPosted

Comandos es algo que le gustaría hacer.Por lo tanto crear nombres que ilustran que:

  • CreateUser
  • UppgradeUserAccount

En cuanto a la organización, por lo general los puse junto con la suma de la raíz que son para. Hace que sea mucho más fácil ver qué puedes hacer y qué tipo de eventos se generan.

Es decir, creo un espacio de nombres para cada agregado raíz y pongo todo debajo de él (definición del repositorio, eventos, comandos).

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

etc.

Cuestiones relacionadas