Pagina 1 di 2
L'architettura software è il livello di decisione che ha l'impatto più lungo sulla vita di un progetto. Una scelta architetturale sbagliata produce debito tecnico per anni; una scelta giusta permette al sistema di crescere senza riscritture traumatiche. Lavoro sull'architettura applicativa da due decenni: dai monoliti modulari ben progettati ai sistemi a microservizi, sempre con pragmatismo.
In questa categoria scrivo di architettura software applicata: quando scegliere un monolite e quando i microservizi, layering applicativo, separazione tra dominio e infrastruttura, event-driven design, strangler-fig per migrazioni incrementali, multi-tenancy. Tutto calato su progetti PHP/Laravel/Symfony reali, con attenzione al cliente PMI che non può permettersi over-engineering.
Se stai per avviare un progetto nuovo o stai valutando un'evoluzione architetturale su un progetto esistente, confrontiamoci prima di scrivere la prima riga. Oppure scopri il mio approccio architetturale.
La migliore architettura è quella che risolve il tuo problema, non quella che impressiona su un curriculum.
Ho costruito tre SaaS multi-tenant in Laravel negli ultimi tre anni con approcci diversi: database per tenant (massimo isolamento, costo elevato), schema per tenant (buon compromesso), colonna tenant_id (semplice, rischio di data leak tra tenant). Vi racconto i trade-off reali e quando ho cambiato idea. Continua a leggere
Un'applicazione Laravel con la logica di business nei controller e le chiamate al database direttamente nei Model è impossibile da testare correttamente. Ho refactorizzato un gestionale HR verso l'architettura esagonale: il dominio ora è testabile senza database, e cambiare da MySQL a PostgreSQL ha richiesto un solo adapter. Continua a leggere
Un'azienda di spedizioni aveva cinque sistemi legacy che dovevano scambiarsi eventi in tempo reale. REST era troppo fragile, RabbitMQ non reggeva i volumi. Ho introdotto Kafka con un client PHP su Swoole: 50.000 eventi al giorno con perdita zero e consumer che ripartono dall'ultimo offset in caso di crash. Continua a leggere
Un'applicazione di reportistica con 50 query analitiche complesse che rallentavano le operazioni transazionali. Con CQRS ho separato i modelli di lettura da quelli di scrittura: le query analitiche usano read model denormalizzati aggiornati asincronamente, le operazioni transazionali volano sul modello normalizzato. Continua a leggere
La 'riscrittura totale' è quasi sempre un errore. Con il pattern Strangler Fig ho aiutato una società logistica a estrarre gradualmente funzionalità dal loro monolite Laravel: prima il modulo di tracking, poi la fatturazione. Due anni dopo, tre microservizi autonomi e il monolite ridotto del 40%, sempre in produzione. Continua a leggere
DDD viene spesso presentato come una soluzione per tutti i problemi architetturali, ma in pratica richiede una comprensione profonda del dominio di business. Vi racconto come l'ho applicato a un'applicazione assicurativa PHP, quali parti del pattern hanno funzionato e quali ho abbandonato come over-engineering. Continua a leggere
Ho valutato GraphQL per il refactoring dell'API di un'applicazione mobile Laravel usata da 10.000 utenti. La promessa del 'un endpoint per tutto' si scontra con la complessità di N+1 problem, autorizzazione fine-grained e caching. Vi racconto l'analisi completa e quando la scelta è giustificata. Continua a leggere
Un gestionale ordini con 14 side effect per ogni conferma d'ordine: email, aggiornamento magazzino, contabilità, notifiche. Tutto in un controller. Ho refactorizzato verso event-driven: un evento OrderConfirmed, undici handler indipendenti, deployment graduale. Il codice è passato da ingestibile a modificabile. Continua a leggere
Un'applicazione che aggregava dati da cinque API legacy diverse aveva un frontend che faceva 40 richieste HTTP per caricare una dashboard. Ho introdotto un BFF Node.js che aggrega, trasforma e cache le risposte: la dashboard si carica con una sola richiesta, il backend PHP non è stato toccato. Continua a leggere
Un cliente mi ha chiesto di trasformare il suo monolite Laravel in microservizi 'perché lo fanno tutti'. Ho fatto l'analisi: 15 sviluppatori, 3 domini di business ben separati, un servizio con requisiti di scaling indipendenti. Alla fine ne abbiamo estratti due soli. Vi racconto i criteri di decisione reali. Continua a leggere
