Da CRUD a Messaggi per Applicazioni Scalabili e Manutenibili
… sfatiamo qualche luogo comune….
Michele AponteCEO/CTO Blexin SrlPresidente DotNetCampaniaMVP ASP.NET/IIS@apomic80 - http://www.tolist.net
SponsorGrazie a
Una architettura 3-tier al giorno, toglie il medico di torno?
PresentationLayer
BusinessLayer
DataLayer
Una architettura 3-tier al giorno, toglie il medico di torno? Ma anche no...
Modello di Dominio
Business Services
Data Access Layer (ORM)
RDBMSApplication
Services
User Interface
Limiti di un’architettura 3-Tier e monomodello
• Scrittura e lettura hanno esigenze diverse• Ci sono applicazioni in cui il numero di letture è
molto diverso dal numero di scritture• Problemi di performance• Manutenibilità con aggiunta di altri moduli
applicativi
Proviamo a separare le responsabilità…
PresentationLayer
Write Model(Business Layer)
DataLayer
Read Model
Command Query Responsibility Segregation
… un altro pochino ...
PresentationLayer
Write Model(Business Layer)
DataLayer
Read Model DataLayer
Command Query Responsibility Segregation
Ok… ma come tengo “sincronizzati” Read Model e Write Model?
PresentationLayer
Write Model(Business Layer)
DataLayer
Read ModelDataLayer
Sincronizzatore(denormalizzatore)
Command Query Responsibility Segregation
Mettiamoci l’anima in
pace: il mondo
non è transazion
ale!
DemoCQRS un passo per volta…
In un sistema del genere sapete cosa ci starebbe proprio bene?
PresentationLayer
Write Model
DataLayer
Read ModelDataLayer
Sincronizzatore(denormalizzatore)
ESB
Quando usare CQRS e i Messaggi• Dividere modello di lettura e scrittura è sempre
una buona idea• Con la messaggistica vi portate a casa un sistema
di comunicazione che potete usare anche per scopi puramente applicativi (estendibilità, comunicazione in plugin, ecc.)• Qualcuno ha detto scalabilità???• Se avete una logica unicamente CRUD… ma vi è
veramente mai capitato?• Non guardate unicamente alla dimensione della
vostra applicazione al momento della nascita...
Domande? Intanto qualche riferimento utile