Pagina 3 di 4
Fare architettura vuol dire prendere bene le poche decisioni che saranno costose da cambiare. Gran parte del valore sta nel rifiutare la complessità che non serve. In questa categoria raccolgo il modo di ragionare sulle scelte strutturali applicato alla realtà delle aziende, dove il budget è finito e ogni decisione ha un conto.
Molto spazio va alle 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. In tutti questi casi cerco di distinguere il pattern che risolve un problema reale da quello adottato per sembrare moderni.
Poi c'è la disciplina del no. Torno spesso su quando i microservizi sono la scelta sbagliata: spezzare un monolite che funziona costa quasi sempre più di quanto rende, e la migrazione, quando ha senso, si fa in modo incrementale con pattern come lo Strangler Fig. Vale lo stesso per il vendor lock-in, che resta una decisione architetturale anche quando sembra una scelta di comodo.
E 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 rende facili i cambiamenti probabili e possibili quelli improbabili. Il resto è over-engineering.
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
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
Tool gratuiti per modellare e documentare:
JSON formatter, Genera tipi da JSON, Convertitore YAML/JSON/TOML.
