Pagina 3 di 4
L'architettura non è disegnare diagrammi eleganti: è prendere le poche decisioni che saranno costose da cambiare, e prenderle bene. La maggior parte del valore sta nel dire di no alla complessità che non serve, non nell'aggiungerne. In questa categoria raccolgo il modo di ragionare sulle scelte strutturali applicato alla realtà delle PMI, dove il budget è finito e ogni decisione ha un conto.
Il primo tema sono le decisioni che pesano. Deep modules con interfacce semplici e implementazioni profonde, service layer e repository dove aggiungono valore, DDD e bounded context quando il dominio è abbastanza ricco da giustificarli, Event Sourcing e CQRS nei rari casi in cui servono davvero. Il filo conduttore è distinguere il pattern che risolve un problema reale da quello adottato per sembrare moderni.
Il secondo tema è la disciplina del no. Il tema ricorrente, qui, è quando i microservizi sono la scelta sbagliata: spezzare un monolite che funziona è quasi sempre un costo travestito da modernità, e la migrazione, quando ha senso, si fa in modo incrementale con pattern come lo Strangler Fig, non con un big-bang. Vale lo stesso per il vendor lock-in, che è una decisione architetturale mascherata da scelta di comodo.
Il terzo tema è l'architettura nell'era dell'AI: codebase pensate per essere leggibili dagli umani (e proprio per questo anche dagli assistenti), la sostituibilità del modello progettata a monte con abstraction layer e fallback, i nuovi protocolli fra agenti e servizi. Sono decisioni nuove, ma la logica con cui si prendono è la stessa di sempre.
Se hai una decisione architetturale importante da prendere, vedi la panoramica dei servizi o i miei progetti PHP senior.
La miglior architettura è quella che rende facili i cambiamenti probabili e possibili quelli improbabili. Il resto è over-engineering.
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
Il motore di raccomandazione di un cliente e-commerce richiedeva librerie Python di ML che non esistono in PHP. Ho estratto quella funzionalità in un microservizio FastAPI che Laravel consulta via HTTP con JWT. Latenza p95 di 40ms, deployment Docker su Hetzner. Vi mostro l'architettura e i pattern di integrazione. 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
Symfony 7.2 porta un utilizzo ancora più estensivo degli attributes PHP 8 che elimina gran parte della configurazione YAML che ho sempre trovato verbosa. Ho migrato un'applicazione da Symfony 6.4 a 7.2 e vi racconto i cambiamenti concreti nel codice, i friction point e i benefici netti in manutenibilità. Continua a leggere
Una PMI lombarda con 8 sviluppatori e un monolite Laravel 10 lento aveva speso quattro mesi e 120.000 euro per migrare a microservizi. Risultato: tre servizi parzialmente funzionanti, zero in produzione, latenza raddoppiata e metà del team impegnato in infrastruttura Docker anziché in feature. La mia raccomandazione: fermare la migrazione, modularizzare il monolite con bounded context, e risolvere i veri problemi di performance. In due settimane il team era tornato produttivo. Continua a leggere
Il vendor lock-in è la condizione in cui un'azienda diventa così dipendente da un fornitore da non poter cambiare senza costi insostenibili. Nelle PMI italiane si presenta in quattro forme. Il caso del cliente padovano che pagava trentunmila euro all'anno di AWS e il decalogo anti-lock-in che applico nei miei progetti. Continua a leggere
Event Sourcing è uno dei pattern più potenti e più mal compresi del 2026. Per molti l'idea di "salvare ogni cambiamento come evento immutabile" sembra la soluzione naturale ai requisiti GDPR/NIS2. Ma su una PMI il costo architetturale è spesso sproporzionato. Quando vale la pena adottare Spatie laravel-event-sourcing v7 con CQRS, e quando un audit-chain leggero è la scelta tecnicamente più onesta. Continua a leggere
Il middleware HTTP implementa il Chain of Responsibility pattern (GoF, 1994) e PSR-15 (PHP-FIG, 2018) lo ha standardizzato. Laravel 11 (PR #6188) ha eliminato Http/Kernel.php spostando la registrazione in bootstrap/app.php con API fluent. OWASP Security Headers Cheat Sheet documenta gli header che un middleware deve impostare per mitigare A05:2021 (Security Misconfiguration). Il terminable middleware esegue dopo l'invio della risposta - ideale per logging e analytics senza impatto sulla latenza. Continua a leggere
Robert C. Martin definisce il Single Responsibility Principle come "un modulo deve essere responsabile verso un solo attore". Un controller Laravel che valida input, calcola totali, aggiorna stock, crea record e invia notifiche ha almeno cinque motivi per cambiare. Il Service Layer (Fowler, PoEAA) e l'Action pattern (Freek Van der Herten) estraggono la logica di business dal controller, e il Service Container di Laravel la rende iniettabile e testabile in isolamento. Continua a leggere
A Novembre 2024 il CTO di una PMI italiana del settore logistico mi contattò dopo aver spezzato un monolite Laravel ben scritto in otto microservizi "per scalare meglio", ottenendo una piattaforma più lenta, più fragile e con il doppio degli incidenti di produzione. Il caso illumina la scelta architetturale sbagliata più diffusa nelle PMI italiane oggigiorno - adottare i microservizi per il motivo sbagliato - e cosa fa uno sviluppatore Laravel e Symfony senior per correggerla. Continua a leggere
Tool gratuiti per modellare e documentare:
JSON formatter, Genera tipi da JSON, Convertitore YAML/JSON/TOML.
