DDD: come elaborare correttamente gli eventi senza utilizzare Event Store o Event Sourcing

Does this make sense or what is wrong with this approach?

A livello di superficie, il diagramma sembra piuttosto rotto. È difficile da dire, perché il tuo diagramma non descrive il contesto della chiamata di pubblicazione.

Ciò che il diagramma sembra implicare è che, invece di copiare lo stato in memoria dell'aggregazione direttamente nel repository, prima decomponiamo tale stato in eventi, copiandoli in un livello di trasporto dei messaggi, indirizzato al repository, che ricostruirà una copia dello stato dell'aggregato con cui originariamente avevamo iniziato?

Questa è una grande complessità da introdurre - dove pensi che la ricompensa stia per succedere?

Ciò che potrebbe cercare è l'approccio di Udi Dahan a gestire gli eventi di dominio , che scrive gli eventi e lo stato aggregato aggiornato nel database insieme.

Il suo approccio in realtà non cambia molto il modello di base - il componente dell'applicazione utilizza il repository per ottenere una copia locale dello stato con cui interagire e quando viene fatto tenta di impegnare le sue modifiche nel repository. È il codice repository a quel punto che estrae sia lo stato che gli eventi del dominio dall'aggregato prima di scriverli nel database.

Nota che, nel modello di Udi, la pubblicazione dell'evento si verifica dopo che la scrittura duratura ha avuto esito positivo.

Aggregate -->
Repository -->
DataStore -->
Domain Event Publisher -->
Subscribers

sarebbe il flusso più normale; che potrebbe possibilmente includere il repository (o l'applicazione) che pubblica gli eventi del dominio dopo l'archivio dati come confermato il commit riuscito della transazione.

In ogni caso, non riconosco dal tuo diagramma un problema che dovresti cercare di risolvere; sembra un'improvvisazione dai soliti schemi, e senza più contesto è difficile diagnosticare se vi è un malinteso fondamentale o una serie davvero insolita di restrizioni che stanno distorcendo la soluzione.

Potrebbe valere la pena aprire una nuova domanda che descrive il problema che stai cercando di risolvere e i vincoli che devono essere soddisfatti, per vedere se qualcuno è a conoscenza della letteratura pertinente.

L'aggiornamento dei dati dagli eventi anche quando non si sta utilizzando l'event sourcing va bene, il tuo approccio va bene. Ma il tuo approccio dipende interamente dalle tue esigenze e da cosa sono esattamente gli aggiornamenti. Il motivo per cui le persone utilizzano l'event sourcing è di avere il registro eventi. Ma di solito non hai bisogno del registro eventi per ogni singola cosa nel tuo progetto, come hai già notato.

Quando non utilizzi il sourcing di eventi e non utilizzerai affatto il registro eventi, dovresti chiederti se hai bisogno di eventi?

Per il semplice aggiornamento che stai dimostrando qui, l'evento è praticamente privo di significato e l'aggiornamento può essere effettuato utilizzando direttamente i valori dall'aggregazione. Aggiungere l'evento solo perché è un sovraccarico non necessario.

Tuttavia , esiste un caso d'uso per eventi di dominio.

Diciamo che hai qualche aggregato che ha 4 metodi per consentire le modifiche. Quando si eseguono tre dei quattro metodi per modificare lo stato interno dell'aggregato, è sufficiente aggiornare l'aggregato anche nel livello dati. Ma quando si esegue il quarto metodo, dopo la persistenza dell'aggregazione, si desidera anche avviare un processo come reazione all'operazione.

Questo caso specifico è modellato molto bene e ordinatamente usando eventi di dominio. Sottoscrivi il tuo bus evento per reagire solo all'evento generato dal quarto metodo e ignorare gli altri tre. Il design è coeso ed elegante.

Ovviamente, l'utilizzo di eventi di dominio come questo ti costringerà ad aggiornare il livello dati dai dati contenuti all'interno degli eventi stessi, come hai dimostrato nella foto.

Non consiglierei di usare gli eventi solo perché suonano alla moda. Usali nei luoghi appropriati e quando ne hai veramente bisogno. Se non lo fai, utilizzare semplici mutatori per aggiornare direttamente le proprietà di un aggregato è completamente soddisfacente.

Penso che il design sia sbagliato per un caso di uso generale. Dai commenti capisco che lo stato sarebbe stato costruito dal repository. Questo è sbagliato perché la logica per aggiornare lo stato dovrebbe rimanere nello stesso posto in cui si richiede lo stato, quindi dovrebbe essere contenuta anche nell'Agenda. In altre parole, l'implementazione del repository conterrebbe logica di business / dominio e questo non è OK.

Se non si desidera utilizzare un archivio eventi, è possibile utilizzare CQRS con una persistenza piatta.