Alkampfer's Place

Il blog di Gian Maria Ricci
posts - 659, comments - 871, trackbacks - 80

My Links

News

Gian Maria Ricci Mvp Logo CCSVI in Multiple Sclerosis

English Blog

Tag Cloud

Article Categories

Archives

Post Categories

Image Galleries

I miei siti

Siti utili

DOMAIN EVENTS ed handler- sync o async?

Mi ricollego ad un post di Alessandro per una personalissima considerazione sul concetto di DOMAIN EVENTS ed HANDLER. Attualmente sto aggiungendo un po di questi concetti ad un sistema legacy, molto anemico, perchè la complessità richiede di iniziare a spostarsi verso una architettura il più possibile CQRS almeno in alcune parti (DOMAIN CONTEXT).

Si inizia dal piccolo, cominciando a generare DOMAIN EVENTS, che all’inizio non sono stati altro che log applicativi per capire “cosa è successo?”, ed ora si iniziano ad usare in congiunzione con gli Handler per risolvere alcuni problemi.

A mio avviso vedo due distinte tipologie di handler, la prima è la categoria dei denormalizzatori, componenti che creano le viste per cqrs, e che in molti casi possono essere asincroni. In generale un handler asincrono è l’asso di briscola per tutte quelle operazioni che l’utente non si aspetta in real time, ma che possono essere eseguite dopo “un po’”. Anche se Udi Dahan sostiene che tutto può essere compensativo, se il sistema nasce con quei concetti nel suo DNA “si può fare” ma su un sistema legacy, iniziare a introdurre logiche di business asincrone, può creare, almeno all’inizio qualche problema.

A questo punto io vedo una seconda categoria di handler, quelli che girano in maniera sincrona, e nei quali un fallimento genererà il rollback di tutta la transazione del comando. Questo va molto contro il concetto di sistema CQRS e compensativo, sono daccordo che la vita reale non è transazionale, però purtroppo ci sono delle logiche per cui ho X operazioni da fare, se una di esse trova un problema debbo annullare tutto. Per tali operazioni l’esecuzione in sincrono è doverosa perchè il sistema legacy è cosi, ed improvvisamente dire “nulla può essere più sincrono” è un pochino pericoloso.

A questo punto la soluzione migliore è far decidere all’handler se deve essere eseguito in sync oppure in async, e quindi è sua responsabilità decidere se un suo fallimento porterà al rollback di tutte le operazioni e eventi legati a quel comando oppure no. Se questo vi fa sentire sporchi (un pochino ci si può sentire) in un sistema legacy questa possibilità viene molto comoda e permette di ridurre la frizione.

Alk.

Print | posted on venerdì 22 giugno 2012 12:51 |

Comments have been closed on this topic.

Powered by:
Powered By Subtext Powered By ASP.NET