Monolite modulare: la potenza del monolite con la struttura dei microservizi

Il falso dilemma: monolite o microservizi

Il dibattito "monolite vs microservizi" presenta una falsa dicotomia. Un monolite non deve essere per forza un Big Ball of Mud dove tutto dipende da tutto. E i microservizi non sono l'unico modo per avere separazione e modularita. Il monolite modulare e la terza via: un'applicazione deployata come un singolo artefatto, ma organizzata internamente in moduli con confini espliciti.

Shopify — una delle piattaforme e-commerce più grandi del mondo — ha scelto il monolite modulare con Rails. GitHub ha un monolite modulare Ruby. Basecamp idem. Non e una scelta per principianti: e una scelta architetturale consapevole che privilegia la semplicità operativa senza sacrificare la struttura.

Cos'e un modulo

Un modulo e una porzione dell'applicazione con:

• Confini espliciti: un namespace dedicato, una directory propria. App\Modules\Orders\, App\Modules\Catalog\, App\Modules\Users\.
• API pubblica: ogni modulo espone un'interfaccia limitata (un Service, un Facade) che gli altri moduli possono usare. Le classi interne sono private al modulo.
• Database isolato (logicamente): ogni modulo possiede le proprie tabelle. Il modulo Orders non accede direttamente alle tabelle del modulo Catalog — passa attraverso l'API pubblica.
• Comunicazione esplicita: i moduli comunicano tramite interfacce definite o eventi, non tramite import diretti di classi interne.

Esempio: un gestionale e-commerce modulare

• Modulo Catalog: gestisce prodotti, categorie, prezzi. Espone CatalogService::getProduct(int $id) e CatalogService::checkAvailability(int $productId, int $qty).
• Modulo Orders: gestisce ordini, carrello, checkout. Chiama CatalogService per verificare disponibilita, non accede alle tabelle prodotti direttamente.
• Modulo Payments: gestisce pagamenti e fatturazione. Riceve eventi OrderPlaced dal modulo Orders.
• Modulo Users: gestisce registrazione, profili, permessi. Gli altri moduli lo usano per autenticazione e autorizzazione.

Ogni modulo può evolvere indipendentemente. Il team che lavora sul Catalog non rischia di rompere gli Orders. Le dipendenze sono esplicite e unidirezionali.

Vantaggi rispetto al monolite classico

• Confini chiari: sai dove finisce un modulo e dove inizia un altro. I refactoring sono localizzati.
• Dipendenze visibili: se un modulo importa classi da un altro, e un code smell visibile — non un accoppiamento nascosto in una query SQL.
• Team scaling: team diversi possono lavorare su moduli diversi con meno conflitti.
• Migrazione futura: se un modulo diventa un collo di bottiglia, estrarlo in un microservizio e fattibile perché i confini sono già definiti.

Vantaggi rispetto ai microservizi

• Deploy singolo: un artefatto, un server, un deploy. Nessun orchestratore, nessun service mesh, nessun distributed tracing.
• Transazioni atomiche: le operazioni cross-modulo possono usare transazioni database. Nei microservizi servono saga e compensazioni.
• Debugging semplice: un processo, uno stack trace, un log. Niente chiamate di rete da debuggare.
• Costo operativo basso: un VPS da 20 EUR/mese invece di un cluster Kubernetes.

Quando scegliere il monolite modulare

• Scegli il monolite modulare quando il team e piccolo-medio (2-10 sviluppatori) e la complessità e nel dominio, non nell'infrastruttura
• Scegli il monolite modulare quando vuoi struttura e separazione senza il costo operativo dei microservizi
• Scegli il monolite modulare come punto di partenza: puoi sempre estrarre un microservizio dopo, ma non puoi facilmente tornare indietro
• Scegli i microservizi solo quando hai team grandi (50+), requisiti di scalabilità asimmetrica reali, e budget operativo adeguato

Il monolite modulare e la scelta pragmatica per la maggior parte dei progetti reali. Non e meno sofisticato dei microservizi — e più disciplinato: richiede la stessa cura nella definizione dei confini, senza la complessità della rete distribuita.

---

👉 Leggi l'articolo completo su iadicola.it