Domain-driven design

CAP, ACID, BASE e Eventual Consistency

CAP, ACID, BASE e Eventual Consistency

Per chi è abituato a lavorare con sistemi centralizzati, costituiti ad esempio da una applicazione monolitica dotata di un unico database relazionale, la realizzazione di un sistema distribuito si presenta ricca di insidie. Ne facevo cenno già in un precedente post in cui cercavo di far luce sui problemi che l’astrazione offerta dai moderni strumenti riesce a nascondere ma non a risolvere del tutto. Uno di questi problemi è legato al concetto di consistenza dei dati sparsi in un sistema distribuito.
Eventi di dominio in Spring framework

Eventi di dominio in Spring framework

Qualche giorno fa un collega mi ha chiesto consigli su come disaccoppiare il codice che gestisce la logica di business dal codice che produce eventuali “reazioni” del sistema all’operazione eseguita. La sua necessità sorgeva dal fatto che l’applicazione su cui sta lavorando, realizzata con Spring framework, sarebbe stata utilizzata da diversi clienti, ciascuno dei quali avrebbe potenzialmente richiesto, per la medesima operazione principale, l’esecuzione di differenti operazioni secondarie. Una soluzione a questo problema è l’introduzione nel sistema degli eventi di dominio.
Sull’organizzazione dei team di sviluppo

Sull’organizzazione dei team di sviluppo

L’argomento in questione è di grande attualità in ufficio ed è per questo che mi sento in dovere di condividere in questo post la mia visione sull’organizzazione ideale dei team di sviluppo, frutto di un decennio di osservazioni delle dinamiche lavorative. Il mio ragionamento parte dalla costatazione che la suddivisione dell’intero organico in diversi gruppi è necessaria ed inevitabile, e non per ragioni organizzative ma antropologiche. I gruppi sociali si formano spontaneamente, pertanto è meglio crearli secondo logiche di produttività.
Il ruolo del dominio nello sviluppo di applicazioni

Il ruolo del dominio nello sviluppo di applicazioni

A scuola abbiamo imparato che per risolvere un problema è utile creare un modello, ovvero una astrazione semplificata della realtà in esame, che contempli solo gli elementi necessari alla descrizione del problema in questione. Ristretto il cerchio alle poche entità che costituiscono il modello individuato, sarà più facile individuare le logiche che ne governano il funzionamento e quindi risolvere il problema. Ma è proprio necessario che il modello attorno al quale realizziamo una applicazione debba essere costruito sul dominio del problema?