In un ambiente di microservizio basato su eventi, gli eventi di dominio sono uguali agli argomenti?

Nel gergo AMQP (il protocollo dietro ad esempio RabbitMQ), un argomento è un mezzo per distribuire messaggi, spesso implementato come un tipo di scambio (" scambio di argomenti "). Viene utilizzato per indirizzare i messaggi agli abbonati utilizzando le chiavi di routing e i modelli di routing.

Nel nostro progetto attuale, gli eventi DDD viaggiano nei messaggi RabbitMQ. Le nostre chiavi di routing dei messaggi hanno la forma: <emitting-bounded-context>.<entity-type>.<event-type> - ad esempio, myContext.customer.created .

A seconda di cosa sono interessati, i clienti possono iscriversi tramite code vincolate da diversi modelli di routing come myContext.# , myContext.customer.* , ecc.

Quindi, gli eventi di dominio non equivalgono agli argomenti ma possono avere un "valore di gerarchia argomento" corrispondente nel sistema di messaggistica, il che significa che il tipo di evento potrebbe trovarsi da qualche parte nell'albero delle possibili chiavi di routing.

La risposta più precisa a "fare questi argomenti riflette sempre gli eventi del dominio", la risposta è "no, non sempre, ma a volte lo faranno".

Alcune definizioni:

• Eventi di dominio sono definiti nel livello dominio e sono cittadini di prima classe del dominio. Possono contenere direttamente riferimenti a entità di dominio e oggetti valore. È possibile definire gestori che verranno richiamati quando viene generato l'evento di dominio.
• Un Argomento è un concetto utilizzato da alcuni sistemi pub / sub che consentono ai sistemi di sottoscrizione di iscriversi all'argomento e ricevere tutti i messaggi inviati a tale argomento. Può essere descritto come un "canale logico" per i messaggi e consente l'architettura "fanout" per la messaggistica.

Puoi certamente usare un argomento per riflettere un evento di dominio, dato che il modello pub / sub per i messaggi inviati all'argomento si adatta bene al concetto di sottoscrizione per gestire un evento - ma non è l'unica cosa che un argomento può essere usato per - potrebbe essere un raggruppamento più generale di messaggi, piuttosto che un evento specifico.

Se si sceglie di creare argomenti per ciascun evento per riflettere gli eventi del dominio, indipendentemente dal fatto che sia necessario un argomento per un determinato evento di dominio dipende dal fatto che si desideri o meno l'evento di dominio pubblicato al di fuori del contesto limitato corrente come parte del lingua pubblicata del contesto o, se vuoi mantenerla interna al dominio, utilizzabile solo all'interno del dominio stesso, entrambi sono validi a seconda dell'evento.

Un modo di pensarci è in termini di architettura esagonale (aka "ports and adapters"). In questa architettura, il confine con il mondo l'applicazione è un adattatore: gli adattatori tipici includono un'API REST, un sistema di messaggistica o un sistema di persistenza.

In questa analogia, un argomento è più come un endpoint URI.

Solitamente non esponi tutte le tue entità tramite endpoint REST API e, quando lo fai, non esporti l'entità esattamente come è definita nel dominio, la esponi in un formato adatto per quell'adattatore.

Allo stesso modo, non esporrà necessariamente tutti gli eventi del tuo dominio tramite argomenti - e quando lo fai, non esporrai l'evento esattamente come è definito nell'evento di dominio, lo esporresti in un formato adatto per l'argomento della messaggistica.

es. un evento dominio potrebbe contenere un riferimento a due entità separate. Il messaggio inviato all'argomento potrebbe essere un blob json con due ID entità