Pagina 2 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.
Ho integrato quattro gestionali italiani diversi con applicazioni Laravel: ognuno aveva una API SOAP degli anni 2000 con documentazione parziale e comportamenti non documentati. Vi racconto il pattern adapter che uso per isolare l'integrazione dal codice applicativo e come gestire le incongruenze dei dati tra sistemi. Continua a leggere
JSON5 estende JSON con commenti, trailing comma, virgolette singole e chiavi non quotate, e in PHP si legge con una libreria drop-in. Ma il consiglio che gira da anni, "sostituisci ovunque json_decode con json5_decode", è sbagliato e può crearti problemi: JSON5 non è un JSON migliore per ogni uso, è un formato pensato per i file che un essere umano scrive a mano. Vediamo dove ha senso, dove va evitato, e come si adotta in un progetto esistente senza fare danni. Continua a leggere
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
Ogni codebase PHP legacy che eredo ha la stessa peste: costanti integer o stringhe magiche per rappresentare stati di business. ORDINE_STATO_1, ORDINE_STATO_2. Con PHP 8 Enums, ho modernizzato un sistema ordini trasformando 40 costanti sparse in enum tipizzati con metodi di dominio. Il codice è diventato leggibile. Continua a leggere
La dependency injection è il pattern che più di ogni altro determina la testabilità del codice PHP. Vi mostro i pattern avanzati che uso in progetti complessi: constructor promotion di PHP 8, binding a interfaccia, lazy proxy per servizi costosi e come scrivere test che non dipendono dall'implementazione concreta. 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
Tool gratuiti per modellare e documentare:
JSON formatter, Genera tipi da JSON, Convertitore YAML/JSON/TOML.
