Monolite modulare vs microservizi in PHP: come decidere

La decisione tra monolite modulare vs microservizi in PHP non si risolve in base al numero di moduli, all'anzianità del codice o alla popolarità di un'architettura. Un'applicazione aziendale può crescere in modo sano all'interno di un unico deployment se mantiene confini chiari. Al contrario, dividerla prematuramente può trasformare semplici chiamate interne in una rete di contratti, code, retry e problemi di coordinamento.

La domanda utile non è «dobbiamo usare i microservizi?», bensì «quale capacità di business deve evolvere, fallire, essere rilasciata o scalare in modo indipendente, e possiamo sostenere il costo di operarla così?». La risposta deve partire dal dominio e dall'operatività reale, non da un diagramma obiettivo.

La crescita funzionale non richiede servizi separati

Aggiungere integrazioni, processi asincroni o aree di prodotto non implica che ciascuna debba avere il proprio servizio. Un monolite può contenere moduli ben delimitati, job in background, code e adapter per sistemi esterni senza perdere coerenza operativa.

Il primo intervento consiste solitamente nel ridurre l'accoppiamento interno. Se un modulo di fatturazione importa direttamente classi degli ordini, modifica le loro tabelle o conosce regole interne di inventario, il problema non si risolve automaticamente spostando il codice in un altro repository. Si trasforma soltanto in accoppiamento di rete e dei dati.

Un monolite modulare mira a far sì che ogni capacità disponga di un'interfaccia interna esplicita, dipendenze direzionate e regole proprie. In PHP, ciò può concretizzarsi in namespace per dominio, contratti applicativi, controller snelli, casi d'uso definiti e adapter per persistenza o API esterne. Il fatto di effettuare il deployment di tutto insieme rimane compatibile con questi confini.

Cosa analizzare prima di cambiare architettura

Prima di discutere di tecnologia, identifichi le capacità di business: per esempio, gestione degli ordini, catalogo, identità, fatturazione, elaborazione documentale o notifiche. Una capacità non equivale necessariamente a un'entità né a una schermata; raggruppa regole e decisioni che dovrebbero cambiare per ragioni simili.

• Responsabile: determini chi mantiene le regole, assegna priorità alle modifiche e risponde in caso di incidenti.
• Dati: identifichi quali informazioni crea e governa ogni capacità, chi può modificarle e quali letture incrociate richiede.
• Flussi critici: disegni il percorso di un'operazione rilevante, incluse validazioni, dipendenze esterne e passaggi asincroni.
• Frequenza di cambiamento: distingua le modifiche frequenti dai cambiamenti occasionali. La frequenza isolata non basta; conta se obbliga a coordinare team o release.
• Profilo di carico: separi il traffico interattivo dai task intensivi in termini di CPU, memoria, storage o chiamate a terze parti.
• Impatto del guasto: stabilisca cosa accade se una capacità si degrada per minuti o ore e se il nucleo del business può continuare a operare.

Questo inventario rivela dipendenze che spesso restano nascoste: transazioni condivise, query dirette a tabelle altrui, regole duplicate nei controller e attività pianificate che aggiornano più domini. Estrarle senza risolverle produce servizi formalmente separati ma funzionalmente intrecciati.

Sei segnali per mantenere un monolite modulare

Questi segnali favoriscono il rafforzamento del design interno anziché la distribuzione delle responsabilità:

1. Le modifiche attraversano di solito più moduli. Se una funzionalità di business richiede di modificare ordini, prezzi e fatturazione in modo coordinato, la separazione può moltiplicare deployment e contratti.
2. La consistenza immediata è centrale. Quando un'operazione necessita di un'unica transazione di database per preservare invarianti critici, un confine distribuito aggiunge complesse decisioni di compensazione.
3. Il team è piccolo o la proprietà delle capacità è condivisa. Più servizi richiedono disciplina operativa, reperibilità, pipeline, versioni e diagnostica per ogni unità.
4. Il carico scala in modo simile. Se i componenti crescono allo stesso ritmo e non esiste un collo di bottiglia isolabile, la separazione non apporta un vantaggio chiaro.
5. I confini di dominio sono ancora instabili. Estrarre una capacità mentre le sue regole, il suo vocabolario e le sue responsabilità cambiano costantemente fissa un confine prematuro.
6. Osservabilità e automazione sono limitate. Senza log strutturati, metriche, trace, alert e deployment ripetibili, ogni salto di rete renderà più costoso indagare su un incidente.

Mantenere il monolite non significa accettare codice globale. L'obiettivo è che il modulo possa evolvere con autonomia logica anche se condivide processo, repository e release con altri.

Sei segnali che giustificano un servizio indipendente

L'estrazione è più difendibile quando si combinano varie di queste condizioni, non quando ne compare una sola:

1. Esiste una responsabilità circoscritta e comprensibile. Il servizio ha una missione concreta, regole coese e un linguaggio di dominio proprio.
2. Può essere proprietario dei propri dati. Gestisce il proprio storage ed espone operazioni, eventi o query concordati, invece di consentire l'accesso diretto alle proprie tabelle.
3. Necessita realmente di deployment indipendenti. Il suo ciclo di cambiamento deve avanzare senza coordinare ogni release con il nucleo.
4. Il suo carico è differenziato. Un processo di conversione, ricerca, generazione di file o calcolo intensivo può richiedere scalabilità e risorse diverse.
5. Il suo guasto può essere isolato. Il sistema può degradarsi in modo esplicito se tale capacità non risponde, mediante retry, stati in sospeso o lavoro differito.
6. Esiste una proprietà operativa sufficiente. Un team o responsabile può gestirne il ciclo di vita, gli alert, gli incidenti, la sicurezza e la compatibilità.

Un'API non trasforma da sola un modulo in un microservizio. L'indipendenza dipende anche da dati, deployment, operatività e capacità di prendere decisioni senza dipendere dagli internals di un'altra applicazione.

Costi che emergono separando le responsabilità

Una chiamata di funzione fallisce in modo diverso da una chiamata HTTP, un messaggio in coda o una query remota. Dopo l'estrazione emergono latenza, timeout, autenticazione tra servizi, rate limit, indisponibilità parziale e versioni incompatibili.

Cambia anche il modello di consistenza. Se un servizio conferma un'operazione e un altro non riceve o non elabora l'evento, occorre decidere come rilevare lo stato, riprovare senza duplicare gli effetti e compensare quando necessario. I consumer di eventi devono essere idempotenti; per esempio, elaborare due volte un messaggio non deve emettere due documenti né addebitare due volte.

L'operatività guadagna complessità: correlazione delle richieste, trace distribuite, dashboard delle metriche, retention dei log, gestione dei segreti, policy di backup e test di ripristino. Inoltre, ogni contratto necessita di regole di compatibilità. Aggiungere campi opzionali è di solito meno dirompente che cambiare la semantica, eliminare campi o riutilizzare uno stato con un nuovo significato.

Architettura di transizione all'interno di PHP

Il percorso a minor rischio consiste nel modularizzare prima di estrarre. Definisca un layer applicativo per ogni capacità, con casi d'uso che ricevano comandi o query e restituiscano risultati ben definiti. Nasconda l'accesso al database dietro repository o port quando ciò rappresenta una dipendenza rilevante; non trasformi ogni classe in un'astrazione priva di scopo.

Il resto del monolite deve utilizzare il modulo tramite la sua interfaccia pubblica interna, non tramite le sue entità o tabelle. Se sono necessarie notifiche asincrone, pubblichi eventi di dominio o di integrazione da un punto controllato. Un pattern transactional outbox può aiutare a registrare il cambiamento di business e l'evento in attesa nella stessa transazione, affinché un processo successivo lo consegni in modo affidabile.

Questa fase consente di verificare se il confine è reale. Se l'interfaccia interna cresce senza sosta, richiede oggetti privati di altri moduli o necessita di transazioni condivise in ogni caso d'uso, non è ancora un candidato solido alla separazione.

Come definire il primo confine di servizio

Il primo servizio deve avere una responsabilità facile da spiegare e una dipendenza limitata dal nucleo. Documenti quattro elementi prima di scrivere l'infrastruttura:

• Responsabilità: quali decisioni prende e quali restano esplicitamente fuori.
• API o eventi: input, output, errori, autenticazione, limiti di tempo e idempotenza.
• Proprietà dei dati: cosa memorizza, quali identificatori esterni conserva e quali informazioni consulta tramite contratti.
• Compatibilità: come coesisteranno producer e consumer durante i cambi di versione, inclusi i messaggi ritardati.

Eviti di progettare un'API come specchio delle tabelle. Un contratto deve esprimere operazioni o fatti di business, non esporre dettagli di persistenza che bloccheranno modifiche successive.

Esempio: elaborazione documentale senza frammentare il backoffice

Consideri un backoffice PHP che gestisce pratiche e deve generare, validare e archiviare documenti. All'inizio, l'elaborazione può vivere come modulo interno: riceve una richiesta di generazione, registra il lavoro, esegue un task asincrono e aggiorna uno stato visibile all'utente.

L'estrazione diventa ragionevole se la generazione consuma risorse molto diverse, necessita di dipendenze di conversione specifiche, riceve picchi propri e può funzionare con una richiesta documentale che contenga i dati minimi necessari. Il servizio documentale non dovrebbe interrogare liberamente le tabelle della pratica. Il backoffice può inviare un ordine con un identificatore, un template applicabile, la versione dei dati e la destinazione; il risultato torna come evento o stato consultabile.

Prima di ciò, è opportuno chiarire che un template definisce la struttura di output, mentre un modello può riferirsi a dati di dominio o a un sistema di IA. Se si introducesse l'IA per classificare documenti, sarebbero necessari un caso d'uso delimitato, valutazione con dati rappresentativi, revisione umana per decisioni sensibili, protezione dei dati, controllo dei costi e un'alternativa manuale o basata su regole quando il provider fallisce.

Verifiche prima dell'estrazione

Non tratti l'estrazione come un deployment tecnico isolato. Definisca un'attivazione graduale per un sottoinsieme controllato di operazioni, distinta dall'annunciare il cambiamento a tutti gli utenti. Mantenga un piano di coesistenza e rollback mentre valida il comportamento.

• Test di contratto tra producer e consumer, oltre a test unitari e di integrazione.
• Metriche di latenza, errori, retry, code in attesa, duplicati e tempo necessario per completare il processo.
• Identificatori di correlazione per seguire un'operazione tra monolite, code e servizio.
• Procedure di ripristino: riesecuzione sicura, riconciliazione degli stati, backup e ripristino.
• Regole esplicite per la degradazione funzionale quando il servizio non è disponibile.
• Un criterio di uscita: quali evidenze dimostreranno che l'estrazione ha ridotto un problema concreto e non ha soltanto spostato la complessità.

La migliore decisione architetturale è quella che protegge l'evoluzione del prodotto senza imporre una piattaforma sproporzionata. Un monolite PHP modulare, misurabile e ben delimitato è spesso il passo corretto finché una capacità non dimostri una necessità verificabile di indipendenza.