Sto facendo CQRS nel modo corretto?

Question

Sto facendo CQRS nel modo corretto?

#1 da (0 voti)

1

Volevo solo chiederti ragazzi se questa architettura CQRS è troppo complessa o sto facendo qualcosa di sbagliato? Quindi, solo per spiegare l'immagine qui sotto:

Dopo che un contesto limitato emette un evento (SomeEventHappended = DTO) che qualcosa è successo, questo evento viene ricevuto in un altro contesto limitato.

Dopo che l'evento viene ricevuto in un altro contesto limitato da saga (noto anche come process manager) e dopo aver deciso quale comando emettere, questo evento viene mappato sul messaggio di comando.
Dopo che il comando saga invia, questo comando viene ricevuto dal gestore comandi. Il gestore comandi caricherà AggregateRoot dal repository e chiamerà un metodo su di esso. Poiché il metodo di dominio chiamato si aspetta oggetti di dominio (e non comandi DTO), devo mappare di nuovo - > comando agli oggetti del dominio.
Dopo che è stato richiamato il metodo su AggregateRoot e poiché mi piacerebbe utilizzare il sourcing di eventi, devo mappare i dati da questi oggetti di dominio a DomainEventForEventSourcing che è anche un nuovo DTO. Quindi posso chiamare il metodo (DomainEventForEventSourcing event) su AggregateRoot.
Quando il metodo reagisce su DomainEvents (quando viene reidratato dall'archivio eventi o quando viene ricevuto per la prima volta) - chiamando il metodo when (), dobbiamo nuovamente mappare i dati, ma questa volta tra DTO DomainOventForEventSourcing e oggetti dominio.

Solo una nota: in questo caso sto utilizzando DTO piuttosto complessi e non sono solo 2-3 Integer o variabili stringa. Di solito tutti i campioni mantengono queste cose semplici, ma quando inizi a creare app reali, non sembra così facile.

Quindi in totale 4 mappature che si verificano ogni volta. Forse è legittimo, ma forse sto donando qualcosa di logoro ...

domain-driven-design cqrs event-sourcing

posta Marko Kraljevic 22.11.2016 - 20:23

fonte

1 risposta

Leggi altre domande sui tag domain-driven-design cqrs event-sourcing

Riutilizzo dei bean java per i test di accettazione REST Spring MVC: gestione degli errori di convalida mediante il plug-in jQuery Validation

score 0 · Accepted Answer

I just wanted to ask you guys if this CQRS architecture is too complex or am I doing something wrong?

Lo schema di base che stai schizzando qui è normale.

La giustificazione per le trasformazioni è che si inviano messaggi attraverso un limite di processo; i messaggi fanno parte dell'API che non corrisponde necessariamente a 1: 1 con i tuoi modelli di dominio.

Ad esempio, una delle proprietà che si desidera avere è la capacità di distribuire nuove implementazioni dei contesti limitati in modo indipendente. Quindi dovresti aspettarti che il messaggio (l'evento) condiviso tra BC abbia una rappresentazione agnostica dell'implementazione (il DTO).

Saga non è proprio il termine giusto da usare qui - il termine in realtà significa qualcosa di diverso dalla cosa normale che stai facendo qui (la saga era un termine popolare in letteratura, perché i primi innovatori erano confusi su questo punto) . La terminologia corrente è che un gestore di processi è responsabile per l'ascolto degli eventi e l'invio dei comandi.

Il termine "mappa" non è corretto: qualsiasi evento dato può comportare zero o più eventi, a seconda della complessità del processo in questione.

Se il gestore dei processi e gli aggregati fanno parte della stessa unità distribuibile, non è necessario necessariamente rimbalzare il comando tramite un DTO; il gestore processi può utilizzare il modello per descrivere il comando e inviarlo direttamente al gestore comandi (inviando un messaggio API attraverso un limite di processo al gestore comandi). In altre parole, il manager di processo non deve inviare comandi allo stesso gestore di comandi che verrebbe utilizzato da un processo esterno.

Quando l'aggregato accetta il comando, gli eventi che produce e applica hanno senso rimanere nella lingua del modello - nessun DTO necessario qui. Tuttavia, quando si scrive quell'evento in un archivio di persistenza o in un bus di messaggi, è probabile che si stia attraversando nuovamente un confine di processo e si vorrà invece utilizzare una rappresentazione stabile. (In particolare, si desidera che l'archivio di persistenza abbia un'implementazione stabile in modo da poter sostituire l'implementazione dell'aggregato stesso.

In breve: la motivazione per l'utilizzo degli DTO è di avere un'API stabile, in modo da poter distribuire le unità in modo indipendente. In genere eseguirai le trasformazioni da / verso le rappresentazioni DTO ai limiti dei tuoi processi.