Monoliti che evolvono

Abstract

Da oltre dieci anni il monolito viene spesso considerato un’architettura immobile, difficile da modificare e quasi impossibile da far evolvere rapidamente per stare al passo con le esigenze del business. Per questo motivo, molti team sono passati a un’architettura a microservizi che, almeno sulla carta, prometteva maggiore manutenibilità ed evolvibilità. Nella realtà, però, ai vecchi problemi se ne sono spessi aggiunti di nuovi.

I microservizi sono sistemi distribuiti complessi e tutt’altro che banali da progettare e gestire. Se non si pone la massima attenzione alla loro reale indipendenza, il rischio è quello di amplificare le criticità tipiche dei cattivi monoliti — come l’alto accoppiamento e la bassa coesione — trasformandoli in un incubo distribuito.

Nel corso degli anni mi sono chiesto più volte come scrivere applicazioni che restino semplici e facili da modificare nel tempo. Per trovare una risposta, sono partito dall’origine del problema: il disallineamento tra i moduli di dominio e la mancanza di confini chiari nel codice.

In questo workshop costruremo insieme un’applicazione — un monolito modulare — pensata per essere facile da mantenere, a ridotta complessità operativa e pronta a evolvere nel tempo. Partendo dai concetti base dei moduli software, vedremo come comporre un’architettura disaccoppiata e solida, predisposta fin da subito all’eventuale estrazione di singoli moduli in servizi indipendenti.

Cosa hanno imparato i partecipanti

Al termine di questo workshop, i partecipanti avranno acquisito strumenti pratici e competenze architetturali per:

• Modellare il dominio con il DDD: identificare e perimetrare i Bounded Context e definire gli Aggregati per creare confini di dominio chiari e coerenti.
• Applicare Clean & Hexagonal Architecture nei moduli: strutturare ogni singolo modulo del monolito in modo isolato, separando la logica di business dai dettagli infrastrutturali.
• Disaccoppiare la comunicazione inter-modulo: implementare pattern di comunicazione sincrona e asincrona (tramite eventi in-memory/bus) per ridurre al minimo le dipendenze dirette tra i componenti.
• Progettare monoliti pronti all’evoluzione: sviluppare software a bassa complessità operativa, alta coesione e basso accoppiamento, già predisposto per l’estrazione futura in microservizi autonomi senza dovere riscrivere l’applicazione.