Categoria

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.

Cloudflare, Coinbase e Lightning hanno appena resuscitato HTTP 402 dopo 29 anni di oblio: ecco come far pagare gli agenti AI che scrapano il tuo sito con Laravel, Symfony e PHP vanilla

Cloudflare, Coinbase e Lightning hanno appena resuscitato HTTP 402 dopo 29 anni di oblio: ecco come far pagare gli agenti AI che scrapano il tuo sito con Laravel, Symfony e PHP vanilla HTTP 402 Payment Required è stato 'reserved for future use' dal 1997. Nel 2026 Cloudflare, Coinbase (x402), Lightning Labs (L402) e Google (AP2) lo hanno finalmente resuscitato per far pagare gli agenti AI che scrapano il web. Ti racconto come ho implementato il pattern nel mio laboratorio personale con Laravel 12, Symfony 7 e PHP vanilla, con numeri reali di 14 giorni di esercizio e la realtà dietro l'hype. Continua a leggere
Ultima modifica:

Servire text/markdown agli agenti AI senza Cloudflare: content negotiation RFC 9110 on-origin con Laravel, Symfony e PHP vanilla

Servire text/markdown agli agenti AI senza Cloudflare: content negotiation RFC 9110 on-origin con Laravel, Symfony e PHP vanilla Claude Code, Cursor e OpenCode mandano già Accept: text/markdown e pagano -80% sui token. Cloudflare ha lanciato 'Markdown for Agents' ma non è l'unica via: implementare la content negotiation RFC 9110 direttamente on-origin ti dà controllo totale senza dipendenze edge. Ti mostro come farlo da Laravel 12, Symfony 7 e PHP vanilla, evitando il falso cloaking di cui parla Mueller. Continua a leggere
Ultima modifica:

Rust per inference edge di modelli leggeri: quando la performance supera la produttività di Python

Rust per inference edge di modelli leggeri: quando la performance supera la produttività di Python Python vince sulla produttività in fase di prototipazione AI. Rust vince in produzione edge quando la latenza e la memoria contano. Framework come Candle, Burn e ort rendono possibile eseguire modelli embedding e di classificazione con binari da 20 MB, latenza sub-millisecondo, memoria bounded. Ti mostro i casi d'uso dove ho sostituito Python con Rust: embedding generator per RAG, classificatori di intent, preprocessing pipeline. Con confronto diretto su benchmark reali. Continua a leggere
Ultima modifica:

L'architettura del codebase AI-friendly: deep modules, AI come dependency, e perché il debito non si refactora da solo

L'architettura del codebase AI-friendly: deep modules, AI come dependency, e perché il debito non si refactora da solo Architetture pensate per umani aiutano l'AI di più di architetture pensate per l'AI. Moduli profondi con interfacce semplici. AI integrata come dependency lenta e non deterministica, dietro circuit breaker e fallback. E la verità che spinge il mercato in direzione opposta: il debito accumulato oggi non sarà refactorato da nessun modello futuro, perché refactoring richiede intent originale, non sintassi. Continua a leggere
Ultima modifica:

Integrazione con sistemi ERP legacy tramite API PHP: pattern e insidie comuni

Integrazione con sistemi ERP legacy tramite API PHP: pattern e insidie comuni 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
Ultima modifica:

Rendere compatibile il proprio codice PHP con lo standard JSON5

Rendere compatibile il proprio codice PHP con lo standard JSON5 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
Ultima modifica:

Architettura esagonale (Ports & Adapters) in Laravel: separare dominio da infrastruttura

Architettura esagonale (Ports & Adapters) in Laravel: separare dominio da infrastruttura 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
Ultima modifica:

PHP 8 Enums: sostituire le costanti di classe e i magic strings nei domini di business

PHP 8 Enums: sostituire le costanti di classe e i magic strings nei domini di business 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
Ultima modifica:

Dependency injection avanzato in PHP 8: costruire servizi testabili e sostituibili

Dependency injection avanzato in PHP 8: costruire servizi testabili e sostituibili 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
Ultima modifica:

Strumenti utili per l'architettura

Tool gratuiti per modellare e documentare:

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