Architettura Software
Pagina 2 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.
Servire text/markdown agli agenti AI senza Cloudflare: content negotiation RFC 9110 on-origin con Laravel, Symfony e PHP vanilla
Rust per inference edge di modelli leggeri: quando la performance supera la produttività di Python
L'architettura del codebase AI-friendly: deep modules, AI come dependency, e perché il debito non si refactora da solo
Integrazione con sistemi ERP legacy tramite API PHP: pattern e insidie comuni
Rendere compatibile il proprio codice PHP con lo standard JSON5
Multi-tenancy in Laravel: strategie di isolamento dati per SaaS PHP
Architettura esagonale (Ports & Adapters) in Laravel: separare dominio da infrastruttura
PHP 8 Enums: sostituire le costanti di classe e i magic strings nei domini di business
Dependency injection avanzato in PHP 8: costruire servizi testabili e sostituibili
Strumenti utili per l'architettura
Tool gratuiti per modellare e documentare:
JSON formatter, Genera tipi da JSON, Convertitore YAML/JSON/TOML.