Definisci più eventi DDD o solo un evento XXXChanged quando usi CQRS?

Question

Definisci più eventi DDD o solo un evento XXXChanged quando usi CQRS?

#1 da (0 voti)
#2 da (0 voti)

2

È preferibile definire un singolo 'evento contenitore' come di seguito:

trait UserStatus
case object Active extends UserStatus
case object Inactive extends UserStatus

case class UserStatusChanged(newStatus: UserStatus, userId: String, eventTime: Long)

o definisci più eventi:

case class UserBecameActive(userId: String, eventTime: Long)
case class UserBecameInactive(userId: String, eventTime: Long)

Il primo approccio sembra più mantenibile richiedendo un numero minore di boilerplate per supportare ulteriori stati utente, ma il secondo sembra più nello spirito del DDD e più vicino agli esempi che ho visto.

domain-driven-design scala

posta Damian 18.11.2018 - 17:59

fonte

2 risposte

Leggi altre domande sui tag domain-driven-design scala

Devo escogitare un'interfaccia FileHandler per gestire file diversi? LSH per un elenco di parole

score 0 · Answer 1

Che tu vada il primo o il secondo modo dipende interamente dalle tue esigenze. Se sei sempre interessato alla situazione in cui un utente diventa attivo e non può preoccuparsi di non diventare più inattivo, definendo solo l'evento UserBecameActive e inviandolo al tuo sistema quando viene attivato un utente sarebbe il modo consigliato di andare . Dopo tutto, perché definire il UserStatusChanged per tutti i tipi di stato, se mai reagirai a questo anche quando il valore della proprietà newStatus è in effetti Active ? Questo è solo un altro if/else nel tuo codice. Grazie a ciò, è possibile definire i gestori di eventi che reagiscono a questo tipo di evento ed eseguire una logica aggiuntiva quando ciò si verifica anche all'interno del proprio sistema, senza la necessità di esaminare i potenziali valori di UserStatusChanged per sapere se l'utente è attivo o meno. Per non parlare, UserBecameActive probabilmente si adatta meglio al tuo linguaggio ubiquitario rispetto all'evento UserStatusChanged .

D'altro canto, avere un approccio troppo granulare non risolverà molto probabilmente tutti i tuoi problemi. Se inizi a introdurre molti tipi di eventi per ogni proprietà (o una cosa importante) di un'entità, molto probabilmente ti imbatterai in una situazione in cui potresti utilizzare più attributi dell'evento, ma l'evento non funzionerebbe correttamente nel tuo dominio. Quindi, forse l'evento con un semplice evento UserHasBeenUpdated potrebbe essere perfettamente ragionevole.

score 0 · Answer 2

Ci sono due possibili definizioni di eventi qui e dovrebbero essere trattati in modo diverso. Se stai parlando di un evento DDD all'interno di un dominio, andrei con i due eventi distinti. Gli eventi di dominio dovrebbero indicare che qualcosa di significativo sta accadendo e deve essere affrontato. C'è un'aspettativa che qualcosa all'interno del dominio gestirà l'evento in modo appropriato. Quando crei un evento di dominio, dovresti avere in mente un gestore specifico. Nota che questo significa che se c'è un codice che deve gestire qualsiasi cambiamento di stato indipendentemente dal nuovo valore, avresti anche bisogno di UserStatusChanged.

Se stai parlando di quali eventi memorizzare in un Event Store, andrei con il generico UserStatusChanged. Questi eventi non dovrebbero incorporare la logica di dominio, riflettono solo le modifiche di stato nel tuo dominio. Se si limita a UserBecameActive e UserBecameInactive, si intende che questi sono gli unici due stati significativi. Capisco che quelli sono probabilmente gli unici due stati che esistono al momento, ma cosa succede quando viene aggiunto un terzo (come "Membership Pending"). Aggiungete ora un terzo evento? Che dire del codice a cui non interessa il valore di UserStatus, solo che è cambiato (gli algoritmi di cache vengono in mente)? Per gli eventi del negozio di eventi, non è necessario avere un gestore specifico in mente.

Gli eventi dell'archivio degli eventi dovrebbero dire "qualcosa è cambiato", non "qualcosa cambiato in un valore importante". Spetta al dominio decidere.

Gli eventi di dominio dovrebbero dire "sta accadendo qualcosa di significativo" indipendentemente dal fatto che ciò comporti un cambiamento di stato o meno.