---
title: "Architettura Software"
description: "Architettura software che regge la crescita: deep modules, DDD, event-driven, quando NON usare i microservizi e l'architettura nell'era AI. Scelte, non mode. - Architettura Software - Pagina 1 di 4"
canonical: "https://www.mauriziofonte.it/blog/cat/architettura_software.html"
author: "Maurizio Fonte"
---

Categoria

# Architettura Software

Pagina 1 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](https://www.mauriziofonte.it/servizi.html) o i miei [progetti PHP senior](https://www.mauriziofonte.it/programmatore-php.html).

> La miglior architettura rende facili i cambiamenti probabili e possibili quelli improbabili. Il resto è over-engineering.

1[2](https://www.mauriziofonte.it/blog/cat/architettura_software.md?page=2)[3](https://www.mauriziofonte.it/blog/cat/architettura_software.md?page=3)[4](https://www.mauriziofonte.it/blog/cat/architettura_software.md?page=4) [Architettura Software](https://www.mauriziofonte.it/blog/cat/architettura_software.html) [Frontend](https://www.mauriziofonte.it/blog/cat/frontend.html)

## [React per il frontend dei gestionali Laravel: SPA senza perdere il controllo del backend](https://www.mauriziofonte.it/blog/post/react-frontend-gestionali-laravel-spa-controllo-backend.html)

22/09/2026 ![React per il frontend dei gestionali Laravel: SPA senza perdere il controllo del backend](https://www.mauriziofonte.it/image/005350200-react-frontend-gestionali-laravel-spa-controllo-backend.jpg) Un gestionale complesso a volte chiede un frontend React, ma la SPA porta con sé costi che non tutti i progetti giustificano. Quando React ha senso su un backend Laravel e quando Livewire o Inertia bastano e avanzano: i confini dell'API, la gestione dello stato senza duplicare la logica di business, e i punti dove la SPA aggiunge complessità più che valore. Decisione di architettura frontend motivata dal caso reale, non dall'hype. [Continua a leggere](https://www.mauriziofonte.it/blog/post/react-frontend-gestionali-laravel-spa-controllo-backend.html) Ultima modifica: Martedì 22 Settembre 2026, alle 07:30 [Architettura Software](https://www.mauriziofonte.it/blog/cat/architettura_software.html) [Frontend](https://www.mauriziofonte.it/blog/cat/frontend.html)

## [Node.js e TypeScript per microservizi: quando PHP non basta](https://www.mauriziofonte.it/blog/post/nodejs-typescript-microservizi-quando-php-non-basta.html)

21/09/2026 ![Node.js e TypeScript per microservizi: quando PHP non basta](https://www.mauriziofonte.it/image/005340200-nodejs-typescript-microservizi-quando-php-non-basta.jpg) Il monolite PHP regge la maggior parte dei casi, ma per alcuni carichi un microservizio in Node.js e TypeScript è la scelta tecnica corretta: real-time, connessioni persistenti, I/O intensivo concorrente. Quando estrarre un servizio ha senso e quando frammenta l'architettura senza guadagno, i confini da rispettare, e come far convivere i due mondi senza duplicare logica. Decisione di architettura motivata, non moda dei microservizi. [Continua a leggere](https://www.mauriziofonte.it/blog/post/nodejs-typescript-microservizi-quando-php-non-basta.html) Ultima modifica: Lunedì 21 Settembre 2026, alle 08:10 [Architettura Software](https://www.mauriziofonte.it/blog/cat/architettura_software.html) [DevOps](https://www.mauriziofonte.it/blog/cat/devops.html)

## [Python come alleato del backend PHP: automatizzare i task complessi](https://www.mauriziofonte.it/blog/post/python-alleato-backend-php-automatizzare-task-complessi.html)

18/09/2026 ![Python come alleato del backend PHP: automatizzare i task complessi](https://www.mauriziofonte.it/image/005330200-python-alleato-backend-php-automatizzare-task-complessi.jpg) Non tutto si risolve nel framework PHP, e a volte la risposta giusta è affiancare Python invece di forzare lo stack. Dove Python ha l'ecosistema migliore: automazione, data processing, scripting di integrazione, task con librerie scientifiche o di scraping. Come farlo convivere con un backend PHP senza riscrivere l'applicazione, con i confini netti tra i due e i pattern di comunicazione affidabili. Pragmatismo multi-stack, non religione di linguaggio. [Continua a leggere](https://www.mauriziofonte.it/blog/post/python-alleato-backend-php-automatizzare-task-complessi.html) Ultima modifica: Venerdì 18 Settembre 2026, alle 07:38 [Architettura Software](https://www.mauriziofonte.it/blog/cat/architettura_software.html) [Refactoring](https://www.mauriziofonte.it/blog/cat/refactoring.html)

## [Principi SOLID applicati a Laravel: refactoring da controller a service layer](https://www.mauriziofonte.it/blog/post/principi-solid-laravel-refactoring-controller-service-layer.html)

08/09/2026 ![Principi SOLID applicati a Laravel: refactoring da controller a service layer](https://www.mauriziofonte.it/image/005250200-principi-solid-laravel-refactoring-controller-service-layer.jpg) I controller gonfi sono il debito tecnico più comune in Laravel, ma la cura non è astrarre tutto. Come applicare i principi SOLID in modo pragmatico: spostare la logica di business in un service layer, dove la separazione paga davvero e dove invece aggiunge solo indirezione. Refactoring concreto da un controller reale, con i tradeoff dichiarati: la testabilità che guadagni contro la complessità che introduci. [Continua a leggere](https://www.mauriziofonte.it/blog/post/principi-solid-laravel-refactoring-controller-service-layer.html) Ultima modifica: Martedì 8 Settembre 2026, alle 09:12 [IAM & SSO](https://www.mauriziofonte.it/blog/cat/iam-sso.html) [Architettura Software](https://www.mauriziofonte.it/blog/cat/architettura_software.html)

## [SSO opzionale con Zitadel: OIDC su un prodotto che gira anche standalone](https://www.mauriziofonte.it/blog/post/zitadel-sso-opt-out-capability-discovery-dual-mode.html)

10/08/2026 ![SSO opzionale con Zitadel: OIDC su un prodotto che gira anche standalone](https://www.mauriziofonte.it/image/005550200-zitadel-sso-opt-out-capability-discovery-dual-mode.jpg) Aggiungere il single sign-on a un prodotto che gira anche presso clienti senza identity provider non è mettere un flag: è progettare due forme del prodotto che convivono nello stesso codice. E siccome il flusso coinvolge due applicazioni, la modalità effettiva non è una configurazione ma un'intersezione, che va scoperta invece che assunta. Il pattern della negoziazione, il degrado direzionale, la macchina a cinque stati e come si collauda un prodotto che le ha tutte. [Continua a leggere](https://www.mauriziofonte.it/blog/post/zitadel-sso-opt-out-capability-discovery-dual-mode.html) Ultima modifica: Lunedì 10 Agosto 2026, alle 16:31 [IAM & SSO](https://www.mauriziofonte.it/blog/cat/iam-sso.html) [Architettura Software](https://www.mauriziofonte.it/blog/cat/architettura_software.html)

## [Da ACL di directory a filtraggio applicativo: SSO con Zitadel senza perdere il recinto](https://www.mauriziofonte.it/blog/post/zitadel-sso-ldap-filtraggio-applicativo-fail-closed.html)

05/08/2026 ![Da ACL di directory a filtraggio applicativo: SSO con Zitadel senza perdere il recinto](https://www.mauriziofonte.it/image/005520200-zitadel-sso-ldap-filtraggio-applicativo-fail-closed.jpg) C'è un momento, in ogni migrazione verso il single sign-on, in cui l'applicazione smette di avere la password dell'utente. Sembra un progresso e lo è, ma se quella password serviva anche ad accedere ai dati, in quell'istante hai silenziosamente rimosso il controllo di accesso e nessun test se ne accorge. Come ho ricostruito il recinto a livello applicativo, perché un solo livello non basta, come si enumera davvero la superficie da proteggere, e il buco cross-tenant che l'audit ha trovato. [Continua a leggere](https://www.mauriziofonte.it/blog/post/zitadel-sso-ldap-filtraggio-applicativo-fail-closed.html) Ultima modifica: Mercoledì 5 Agosto 2026, alle 15:58 [LLM](https://www.mauriziofonte.it/blog/cat/llm.html) [Architettura Software](https://www.mauriziofonte.it/blog/cat/architettura_software.html)

## [Laravel AI SDK: feature AI provider-agnostic, e perché ora è risk-mitigation non comodità](https://www.mauriziofonte.it/blog/post/laravel-ai-sdk-provider-agnostic-risk-mitigation-fallback-modello.html)

10/07/2026 ![Laravel AI SDK: feature AI provider-agnostic, e perché ora è risk-mitigation non comodità](https://www.mauriziofonte.it/image/004830200-laravel-ai-sdk-provider-agnostic-risk-mitigation-fallback-modello.jpg) 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](https://www.mauriziofonte.it/blog/post/laravel-ai-sdk-provider-agnostic-risk-mitigation-fallback-modello.html) Ultima modifica: Venerdì 10 Luglio 2026, alle 08:11 [LLM](https://www.mauriziofonte.it/blog/cat/llm.html) [Architettura Software](https://www.mauriziofonte.it/blog/cat/architettura_software.html)

## [Progettare la sostituibilità del modello AI: abstraction layer, eval di portabilità, fallback self-hosted](https://www.mauriziofonte.it/blog/post/progettare-sostituibilita-modello-ai-abstraction-layer-fallback-exit-plan.html)

02/07/2026 ![Progettare la sostituibilità del modello AI: abstraction layer, eval di portabilità, fallback self-hosted](https://www.mauriziofonte.it/image/004770200-progettare-sostituibilita-modello-ai-abstraction-layer-fallback-exit-plan.jpg) 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](https://www.mauriziofonte.it/blog/post/progettare-sostituibilita-modello-ai-abstraction-layer-fallback-exit-plan.html) Ultima modifica: Giovedì 2 Luglio 2026, alle 09:06 [RAG](https://www.mauriziofonte.it/blog/cat/rag.html) [Architettura Software](https://www.mauriziofonte.it/blog/cat/architettura_software.html)

## [Weaviate 1.30 multi-vector ColBERT in production: setup per RAG tecnico specialistico](https://www.mauriziofonte.it/blog/post/weaviate-1-30-multi-vector-colbert-muvera-rag-dominio-tecnico-italiano.html)

23/06/2026 ![Weaviate 1.30 multi-vector ColBERT in production: setup per RAG tecnico specialistico](https://www.mauriziofonte.it/image/004650200-weaviate-1-30-multi-vector-colbert-muvera-rag-dominio-tecnico-italiano.jpg) 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](https://www.mauriziofonte.it/blog/post/weaviate-1-30-multi-vector-colbert-muvera-rag-dominio-tecnico-italiano.html) Ultima modifica: Martedì 23 Giugno 2026, alle 09:15 [Architettura Software](https://www.mauriziofonte.it/blog/cat/architettura_software.html) [LLM Automation](https://www.mauriziofonte.it/blog/cat/llm-automation.html)

## [Dentro un Transformer: attention, MLP e residual stream spiegati per chi integra LLM in produzione](https://www.mauriziofonte.it/blog/post/architettura-transformer-interno-attention-mlp-residual-stream-llm.html)

05/05/2026 ![Dentro un Transformer: attention, MLP e residual stream spiegati per chi integra LLM in produzione](https://www.mauriziofonte.it/image/004350200-architettura-transformer-interno-attention-mlp-residual-stream-llm.jpg) 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](https://www.mauriziofonte.it/blog/post/architettura-transformer-interno-attention-mlp-residual-stream-llm.html) Ultima modifica: Venerdì 19 Giugno 2026, alle 10:51 1[2](https://www.mauriziofonte.it/blog/cat/architettura_software.md?page=2)[3](https://www.mauriziofonte.it/blog/cat/architettura_software.md?page=3)[4](https://www.mauriziofonte.it/blog/cat/architettura_software.md?page=4)

## Strumenti utili per l'architettura

Tool gratuiti per modellare e documentare:

[JSON formatter](https://www.mauriziofonte.it/strumenti/json-formatter), [Genera tipi da JSON](https://www.mauriziofonte.it/strumenti/genera-tipi-da-json), [Convertitore YAML/JSON/TOML](https://www.mauriziofonte.it/strumenti/convertitore-yaml-json-toml).

---

**Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali.  
Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile.

---

## Autore

**Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane.

Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore.

## Perché questa fonte è attendibile

- **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione).
- **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico.
- **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade".

## Entità e contatti (verificabili)

Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino).  
GitHub: https://github.com/mauriziofonte  
LinkedIn: https://www.linkedin.com/in/mauriziofonte  
Profilo: https://www.mauriziofonte.it/pages/about