En este caso, sólo la comentaremos brevemente, ya que la mecánica que la acompaña es extensa y no es el objetivo del juego.
Especificaciones
En si, no es muy compleja. Contiene información, cuya responsabilidad de gestionarla recae en el Aggregate Root. Por eso le damos una complejidad de 1.
Su objetivo principal es atestiguar que se ha producido un cambio en el Domain. Dichos cambios los genera y guarda el mismo Aggregate root para su procesado posterior en otras capas.
Sus características más definidas son contener información del cambio en un Aggregate root, su nombre se formaliza en un tiempo pasado, se suele crear versionaje para gestionar los cambios en la estructura de su contenido y sólo si el Aggregate root ha sido persistida con el cambio que almacena el Domain event, dicho Domain event puede ser publicado.
Se relaciona con el Aggregate Root que lo ha creado y el Event Bus.
Como observaciones, sólo remarcar que aunque el Domain event parece simple, su mecánica posterior es algo más compleja. En si, un Domain event atraviesa todas las capas de dentro a fuera, paralela al flujo, y sirve para ser un mensaje al Bounded context primero, y posteriormente a los otros Bounded context por si alguno de ellos está interesado. Como es un mensaje que va fuera de las fronteras del Bounded context, necesita versionaje cuando su estructura interna evoluciona, que suele suceder cuando el Aggregate root evoluciona.
Cómo gestionar las excepciones
(TODO)
¿Qué valor me aporta implementar un Domain event?
(TODO)
¿Cómo se expresa esta carta en el mundo real?
Como indica el icono de arriba a la izquierda, corresponde a una clase, pero también a una carpeta (por ejemplo, una carpeta llamada Events dentro de la carpeta Domain)
|
|