Modular Monolith: il passo spesso più importante

Il problema

Un monolite può diventare un Big Ball of Mud perché i confini interni non sono espliciti e i moduli accedono liberamente ai dettagli degli altri.

Il pattern

Organizzare l'applicazione in moduli con ownership, API interne e dipendenze controllate, conservando un unico deploy quando la distribuzione non porta ancora un beneficio netto.

Come funziona

Ogni modulo espone operazioni e modelli pubblici limitati; le dipendenze tra moduli sono direzionali e verificate. Il database può essere fisicamente comune, ma gli schemi e l'accesso ai dati restano logicamente posseduti dai moduli.

Esempio sanitario

Benefici

• Semplifica test e deployment
• Prepara l'estrazione selettiva
• Riduce coupling senza introdurre rete

Trade-off

• Richiede disciplina sui confini
• Non offre scalabilità indipendente per modulo

Quando usarlo

Quando il dominio è complesso ma il costo dei microservizi non è ancora giustificato.

Quando evitarlo

Quando servono davvero isolamento di failure domain, scalabilità o deployment indipendenti.

Pattern correlati