Categoria

Pagina 1 di 4

Architettura Software: scelte che reggono la crescita, non slide da conferenza

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.

Laravel AI SDK: feature AI provider-agnostic, e perché ora è risk-mitigation non comodità

Laravel AI SDK: feature AI provider-agnostic, e perché ora è risk-mitigation non comodità Il AI SDK first-party di Laravel porta text generation, tool-calling ed embeddings con uno switch di provider gestito da config. Fino a ieri lo si vendeva come comodità; dopo la sospensione di Fable 5 del 12 giugno 2026 è risk-mitigation: chi ha l'abstraction layer agnostico fa fallback in una riga quando un modello viene spento dall'alto, chi è cablato si ferma. Esempio concreto con un provider primario e un fallback, e cosa serve perché lo switch sia davvero indolore. Continua a leggere
Ultima modifica:

Progettare la sostituibilità del modello AI: abstraction layer, eval di portabilità, fallback self-hosted

Progettare la sostituibilità del modello AI: abstraction layer, eval di portabilità, fallback self-hosted Dopo la sospensione di Fable 5 del 12 giugno 2026, la domanda per chi sviluppa con l'AI non è più solo "quale modello" ma "cosa succede quando il modello sparisce". La risposta è architetturale: un abstraction layer provider-agnostic (Laravel AI SDK, LiteLLM), eval di portabilità che misurano la regressione cambiando modello, un fallback multi-provider o self-hosted, e un exit plan documentato. Non significa non usare i frontier model: significa progettarne la sostituibilità prima che serva. Continua a leggere
Ultima modifica:

Weaviate 1.30 multi-vector ColBERT in production: setup per RAG tecnico specialistico

Weaviate 1.30 multi-vector ColBERT in production: setup per RAG tecnico specialistico Per un RAG su dominio tecnico specialistico (vocabolario italiano, sigle proprietarie, convenzioni di settore), un dense bi-encoder single-vector generalista sbaglia spesso. Weaviate 1.30 porta multi-vector ColBERT in GA e 1.31 aggiunge MUVERA per ridurre il footprint. Setup completo: ingestion pipeline, configurazione schema Weaviate, retrieval con late interaction, benchmark accuracy su dataset tecnico italiano della mia sandbox. Continua a leggere
Ultima modifica:

Dentro un Transformer: attention, MLP e residual stream spiegati per chi integra LLM in produzione

Dentro un Transformer: attention, MLP e residual stream spiegati per chi integra LLM in produzione GPT-4 ha ~1.800 miliardi di parametri; il modello legge il prompt in quattro componenti: embedding lookup, multi-head self-attention, MLP, unembedding+softmax. L'attention fa parlare i token fra loro, l'MLP inietta fatti, il residual stream è un nastro che trasporta i vettori ricorsivamente per decine di transformer block. Capire questo rende prevedibili allucinazioni, dipendenza dal prompt, sensibilità all'ordine. Continua a leggere
Ultima modifica:

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:

Strumenti utili per l'architettura

Tool gratuiti per modellare e documentare:

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