Event Store si occupa di eventi di dominio o rappresentazione di eventi di dominio

0

Sto iniziando una nuova architettura DDD e ho un dilemma con gli eventi di dominio e il modo in cui vengono recuperati e archiviati in un database EventStore.

Prima di tutto, l'EventStore dovrebbe vivere nel livello Dominio o nel livello applicazione? Al momento ha più senso per me averlo nel livello applicazione dal momento che il dominio non dovrebbe preoccuparsi di "archiviare" eventi, semplicemente consumandoli.

In secondo luogo, immaginiamo che un evento di dominio abbia una proprietà che è una classe astratta o un'interfaccia, qualcosa che non può essere serializzato o deserializzato senza conoscere l'implementazione concreta. È permesso? O gli eventi del dominio dovrebbero essere serializzabili / deserializable?

Se, come immagino, questo è permesso perché gli eventi di dominio sono significativi all'interno della nostra logica aziendale e non dovrebbero preoccuparsi di essere trasferiti, significa che i nostri eventi di dominio dovrebbero essere mappati a una rappresentazione DTO di eventi che possono essere trasferiti ad altri sistemi (es .: inserito in un bus) o memorizzato (es: persistente in un negozio di eventi). In alcuni posti li chiamano Integration Events. Li chiamo Event DTOs

Questo lascia il livello Applicazione come l'unico posto in cui l'EventStore potrebbe vivere. Pertanto, l'event store si occupa di memorizzare / recuperare i DTO degli eventi (perfettamente serializzabili / deserializzabili).

È corretto? E, cosa più importante, hai un buon link che parla di queste preoccupazioni? Sto davvero lottando per decidere in quale livello lasciare le cose.

    
posta iberodev 03.08.2018 - 22:07
fonte

1 risposta

1

La maggior parte delle discussioni sull'archiviazione di eventi in un archivio di eventi prende in prestito la lingua dal libro blu di Eric Evans. Il Capitolo 6 descrive il ciclo di vita delle entità all'interno del modello di dominio, e in particolare la nozione di un'astrazione "il repository" che fornisce all'applicazione l'illusione che tutte le entità possano essere recuperate da una collezione in memoria.

Quindi il repository è un'astrazione, e i dettagli effettivi di implementazione del caricamento e della memorizzazione degli eventi sopravvivono.

Se hai intenzione di insistere su "livelli", allora hai ragione - non sarà affatto nel modello di dominio, il repository è puramente un problema di applicazione / infrastruttura.

In questi giorni, è più probabile che tu senta la terminologia di "porte e adattatori": il repository è un'astrazione della connessione al database / archivio di eventi.

Or should the domain events be serializable/deserializable?

La maggior parte delle implementazioni tende a memorizzare eventi utilizzando una serializzazione dei messaggi: JSON, Avro, Protocol Buffers e così via. Una sorta di struttura dati immutabile; ci sono alcuni casi in cui è necessario uno schema su misura per la memorizzazione degli eventi, ma nel complesso una soluzione per le materie prime è l'idea giusta qui.

Questa rappresentazione può o meno corrispondere a ciò che usi in memoria. In teoria, potrebbe usare direttamente l'array di byte JSON, ma è più probabile che lo analizzi una volta per creare un DOM o un tipo di valore personalizzato.

In some places they call them Integration Events.

Attenzione: la distinzione comune tra "eventi di dominio" e "eventi di integrazione" ha un significato diverso da quello che stai usando qui.

Is that correct?

Praticamente. Penso che il modo più semplice per tenerne traccia è questo; dovresti essere in grado di cambiare il tuo modello di dominio da una versione all'altra. Gli eventi sono un tipo di messaggio dal vecchio modello al nuovo modello: gli eventi devono essere stabili per periodi di tempo più lunghi rispetto al modello di dominio.

do you have a good link that talks about these concerns?

Greg Young: Controllo delle versioni in un sistema Sourced evento

    
risposta data 04.08.2018 - 06:07
fonte

Leggi altre domande sui tag