La specializzazione fa la forza!

Storia dello sviluppo di una soluzione orientata ai servizi che grazie all’Event sourcing ci ha permesso di toccare con mano i benefici di questo tipo di architettura software.

16 lug 2015

Storia dello sviluppo di una soluzione orientata ai servizi che grazie all’Event sourcing ci ha permesso di toccare con mano i benefici di questo tipo di architettura software.

 

OMB, un nostro cliente operante nel settore della meccanica manifatturiera ha espresso l’esigenza di monitorare e gestire il carico della produzione con particolare riguardo ai processi che, a fronte di un guasto o un difetto rilevati, subissero durante il loro percorso un ricondizionamento.

 

L’applicazione sviluppata ha dovuto integrarsi con un sistema già esistente in azienda che si preoccupa della gestione della produzione a livello generale ma senza scendere nel particolare richiesto al nuovo progetto.

 

Analizzando lo scenario ci è parso subito chiaro che la condizione fosse quella ideale per operare una divisione in bounded context creando un Anti-Corruption Layer (sostanzialmente si tratta di uno strato di traduzione con funzioni difensive, che ci consente di tenere pulito il nostro modello di dominio tenendo al di fuori di esso tutto ciò che potrebbe crearci problemi).

 

Questi messaggi vengono memorizzati in code gestite da Rabbit MQ (un message-oriented middleware) e poi instradati verso il destinatario corretto tramite NServiceBus (un framework di message brokering).

 

Quali vantaggi porta un architettura del genere?

 

Prima di tutto la scalabilità: se l’applicazione è un blocco unico (che non può essere diviso), ciò implica un carico di lavoro più pesante per il server su cui l’applicazione risiede.

 

Con un approccio orientato ai servizi invece è possibile “dividere” l’applicazione in tante piccole applicazioni (micro servizi), ognuna con le proprie responsabilità e indipendenti l’una dall’altra. Questo ci permette, ad esempio, di installare singoli moduli su macchine diverse e quindi distribuire il carico di lavoro.

 

Il secondo vantaggio è rappresentato dal fatto che durante la fase di deploy non è più necessario bloccare interamente il lavoro del cliente, ma è possibile fermare esclusivamente (e sicuramente per un tempo inferiore) il lavoro di un determinato servizio, quello che fa uso del bounded context che stiamo appunto deployando.

 

Altro vantaggio di questa “specializzazione estrema” dei vari moduli è la possibilità che ci offre di individuare e correggere bug e malfunzionamenti più facilmente e velocemente.

 

E infine sempre grazie a questo tipo di architettura, se il bounded context non è attivo quando un messaggio viene generato oppure se l’handler di un messaggio va in errore per qualche motivo, i messaggi che arrivano in quel frangente non vanno persi ma semplicemente restano nella coda di attesa e dopo il fix saranno letti ed eseguiti come se nulla fosse successo.

 

Insomma, un bel passo avanti soprattutto per la qualità del servizio al cliente. Si può migliorare ancora?

 

Certo! Come prossimo passo ad esempio vogliamo dividere il modello di scrittura da quello di lettura per gestire meglio la complessità come teorizzato dal pattern CQRS (e solo accennato nelle release finora deployate).

 

Vi terremo informati!