Categoria

Architettura Software

Pagina 4 di 4

Architettura Software: scelte che reggono la crescita

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.
Architettura Software Performance

Quando i microservizi sono la scelta sbagliata per il tuo monolite Laravel: il caso di una PMI lombarda

Quando i microservizi sono la scelta sbagliata per il tuo monolite Laravel: il caso di una PMI lombarda 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
Ultima modifica:
Compliance Architettura Software

Vendor lock-in nei progetti PHP delle PMI italiane: come ho liberato un cliente padovano da trentunmila euro l'anno di AWS e dall'unico sviluppatore che capiva il suo gestionale

Vendor lock-in nei progetti PHP delle PMI italiane: come ho liberato un cliente padovano da trentunmila euro l'anno di AWS e dall'unico sviluppatore che capiva il suo gestionale 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
Ultima modifica:
Architettura Software Compliance

Event Sourcing con Laravel nel 2026: quando ha senso per una PMI e quando bastano alternative più semplici

Event Sourcing con Laravel nel 2026: quando ha senso per una PMI e quando bastano alternative più semplici 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
Ultima modifica:
Sicurezza Applicazioni Architettura Software

Middleware Laravel 12: da Kernel.php a bootstrap/app.php con security headers, rate limiting e terminable middleware

Middleware Laravel 12: da Kernel.php a bootstrap/app.php con security headers, rate limiting e terminable middleware 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
Ultima modifica:
Architettura Software Refactoring

Fat Controller in Laravel 12: dal controller da 200 righe a Service Layer, Action pattern e Dependency Injection

Fat Controller in Laravel 12: dal controller da 200 righe a Service Layer, Action pattern e Dependency Injection 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
Ultima modifica:
Symfony Architettura Software

Sviluppatore Laravel e Symfony senior: quando i microservizi hanno davvero senso e quando sono un costo mascherato da modernità

Sviluppatore Laravel e Symfony senior: quando i microservizi hanno davvero senso e quando sono un costo mascherato da modernità 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
Ultima modifica:
Laravel Architettura Software

Strategy pattern in Laravel: selezione dinamica di implementazioni con Service Container, contextual binding e Pennant

Strategy pattern in Laravel: selezione dinamica di implementazioni con Service Container, contextual binding e Pennant Lo Strategy pattern - un behavioral pattern del Gang of Four - in Laravel si implementa con il Service Container: bind() per il default, when()->needs()->give() per eccezioni contestuali, e Feature::active() di Pennant per switching runtime basato su feature flag. Nessuna factory custom necessaria. Continua a leggere
Ultima modifica:
Architettura Software Refactoring

Refactoring applicazione Laravel 10: guida passo-passo per adottare la struttura snella di Laravel 12 e centralizzare la configurazione

Refactoring applicazione Laravel 10: guida passo-passo per adottare la struttura snella di Laravel 12 e centralizzare la configurazione Laravel 11 ha introdotto la struttura slim che elimina Http/Kernel, Console/Kernel e la maggior parte dei Service Provider, centralizzando tutto in bootstrap/app.php. La guida ufficiale dice che la migrazione non è obbligatoria - ma in un applicativo con logica custom sparsa tra Kernel e Provider, adottarla riduce il boilerplate e la superficie di manutenzione. Continua a leggere
Ultima modifica:

Strumenti utili per l'architettura

Tool gratuiti per modellare e documentare:

JSON formatter, Genera tipi da JSON, Convertitore YAML/JSON/TOML.