Pagina 4 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.
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
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
Tool gratuiti per modellare e documentare:
JSON formatter, Genera tipi da JSON, Convertitore YAML/JSON/TOML.
