Domain-Driven Design e AI: il problema non è il codice ma il significato

Perché il significato diventa il vero problema nell’era dell’AI-generated code

Negli ultimi anni abbiamo assistito a un cambiamento radicale nel modo in cui produciamo software. Con l’arrivo degli LLM, scrivere codice non è mai stato così veloce e accessibile. Funzioni, API, test, operazioni di refactoring e persino interi servizi possono essere generati in pochi secondi, trasformando attività che fino a poco tempo fa richiedevano ore di lavoro in operazioni quasi istantanee.

È facile lasciarsi trascinare da questa accelerazione e concludere che il problema principale dello sviluppo software sia ormai stato risolto. Se possiamo produrre codice in modo sempre più rapido, allora sembrerebbe naturale immaginare un futuro in cui la progettazione software perda progressivamente importanza, sostituita dalla capacità di orchestrare strumenti generativi sempre più sofisticati.

Eppure, osservando più attentamente ciò che accade nei progetti reali, emerge un problema molto diverso.

Il rischio principale non è produrre codice sbagliato. È produrre sistemi semanticamente errati.

Questa distinzione è fondamentale.

Molte discussioni sull’utilizzo dell’AI nello sviluppo software si concentrano sulle cosiddette “hallucination” (allucinazioni): API inesistenti, errori sintattici, vulnerabilità o implementazioni inefficienti. Sono problemi reali, naturalmente, ma non rappresentano l’aspetto più critico dell’AI-generated code.

Un LLM può produrre codice perfettamente compilabile, coerente con i pattern architetturali più diffusi e persino elegante dal punto di vista implementativo, pur modellando in modo scorretto il dominio aziendale. Non perché “non funzioni”, ma perché manca una reale comprensione della conoscenza dei concetti che sta manipolando.

I modelli linguistici non comprendono il dominio. Completano statisticamente spazi semantici incompleti.

Quando il linguaggio umano è ambiguo, l’AI tende a riempire i vuoti utilizzando correlazioni probabilistiche. E proprio qui il problema si amplifica: la velocità della generazione automatica aumenta enormemente la velocità con cui possiamo produrre implementazioni plausibili, ma semanticamente sbagliate.

La vera novità non è l’automazione del coding

In realtà, l’idea di ridurre il costo della produzione di codice non è affatto nuova.

La storia dell’ingegneria del software è, da sempre, una storia di astrazione. Linguaggi ad alto livello, framework, generatori di codice, CASE tools, model-driven development, piattaforme low-code: per decenni abbiamo costruito strumenti con l’obiettivo di allontanarci progressivamente dalla scrittura manuale del codice.

In questo senso, gli LLM non rappresentano una rottura totale con il passato. Rappresentano piuttosto un’accelerazione estrema di una direzione già esistente.

La vera novità introdotta dall’AI generativa non è quindi l’automazione del coding, ma la velocità con cui possiamo ottenere implementazioni plausibili.

Ed è proprio questo cambiamento a spostare il centro del problema.

Se generare codice diventa estremamente economico, allora il valore non può più concentrarsi nella semplice produzione di implementazioni. Il rischio principale si sposta progressivamente verso il significato del sistema che stiamo costruendo.

L’ambiguità presente nel linguaggio umano non scompare. Viene semplicemente amplificata dalla velocità della generazione automatica.

Ed è qui che molte pratiche architetturali, considerate per anni semplici discipline di modellazione o strumenti organizzativi, tornano improvvisamente centrali.

Il Domain-Driven Design come sistema semantico

Per molto tempo il Domain-Driven Design è stato raccontato soprattutto come una metodologia di modellazione architetturale. Aggregati, Entity, Repository, Eventi e Value Object sono spesso stati interpretati come pattern tecnici o convenzioni implementative.

Nell’era dell’AI-assisted development questa interpretazione rischia però di diventare riduttiva.

Il vero valore del DDD non è la struttura del codice che produce, ma la sua capacità di rendere esplicita la conoscenza del dominio.

Ubiquitous Language e Bounded Context non servono semplicemente a “organizzare meglio” il software. Servono a costruire confini semantici chiari, all’interno dei quali termini, comportamenti e regole mantengono una conoscenza coerente e condivisa.

Un comando ben nominato non rappresenta soltanto un’azione tecnica: rende esplicita un’intenzione del dominio. Un Domain Event non è semplicemente un messaggio scambiato tra componenti, ma la rappresentazione di un fatto accaduto nel business. Un Value Object non è una struttura dati elegante, ma un modo per preservare coerenza semantica attorno a un concetto.

In questo senso il DDD riduce lo spazio interpretativo.

Ed è esattamente ciò di cui abbiamo bisogno quando parte della produzione software viene affidata a sistemi statistici.

Ridurre il contesto significa ridurre l’entropia

Uno dei limiti principali degli LLM riguarda la gestione del contesto. Più il contesto è ampio, ambiguo e semanticamente incoerente, più aumenta la probabilità di ottenere implementazioni errate o incoerenti.

Per questo motivo il concetto di Bounded Context assume oggi un’importanza ancora maggiore rispetto al passato.

Un Bounded Context non rappresenta semplicemente una suddivisione architetturale o organizzativa. È un confine semantico. All’interno di quel confine il linguaggio mantiene significati precisi, le regole restano coerenti e le responsabilità risultano chiaramente definite.

Questa separazione non migliora soltanto la qualità della progettazione software. Migliora direttamente la qualità della generazione assistita dall’AI.

Ridurre il contesto significa ridurre l’entropia semantica. Significa diminuire lo spazio di interpretazione lasciato al modello linguistico e aumentare la probabilità che il codice prodotto rifletta davvero il dominio che stiamo modellando.

Il ruolo dell’Ubiquitous Language

Se il linguaggio è il punto di ingresso dell’AI nel dominio, allora la qualità del linguaggio diventa un fattore progettuale critico.

Un termine ambiguo utilizzato nei requisiti, nella documentazione o nei prompt può generare implementazioni differenti e incoerenti.

Al contrario, un linguaggio condiviso riduce drasticamente lo spazio interpretativo e permette ai modelli di operare all’interno di confini semantici più chiari.

Per ulteriori approfondimenti, invito a leggere il mio articolo “Ubiquitous Language come sistema di controllo per lo sviluppo assistito da LLM” pubblicato in questo blog.

Quando il codice diventa volatile

Per molto tempo abbiamo trattato il codice come il principale contenitore della conoscenza architetturale di un sistema. Le decisioni di design, i vincoli di dominio e persino parte del linguaggio aziendale finivano inevitabilmente inglobati nell’implementazione.

L’AI generativa cambia profondamente questa dinamica.

Il codice prodotto da un LLM è, per sua natura, volatile. Può essere rigenerato, sostituito, rifattorizzato automaticamente o reinterpretato da modelli differenti nel giro di pochi minuti. In un contesto simile, affidare al codice il ruolo di unico custode della conoscenza architetturale diventa sempre più fragile.

La conoscenza del dominio deve quindi spostarsi altrove.

Specifiche, “living documentation”, Architecture Decision Record e modelli semantici condivisi smettono di essere semplici strumenti di supporto. Diventano il vero sistema di memoria dell’architettura.

Se il codice può essere rigenerato continuamente, allora ciò che deve sopravvivere non è l’implementazione, ma il significato.

Il futuro non è meno architettura

Molti immaginano che l’AI renderà progressivamente meno importante la progettazione software. Probabilmente accadrà esattamente il contrario.

Quando il costo della generazione tende a zero, aumenta enormemente il valore della coerenza. Il problema non sarà più riuscire a produrre codice, ma garantire che il sistema continui a rappresentare correttamente il dominio aziendale mentre evolve a velocità sempre maggiori.

In questo scenario il ruolo dell’architetto software cambia profondamente. Non è più soltanto colui che definisce strutture tecniche o supervisiona implementazioni. Diventa il progettista del linguaggio, dei vincoli e dei confini semantici che permettono al sistema di rimanere coerente nel tempo.

Il Domain-Driven Design, quindi, smette di essere soltanto una metodologia di modellazione. Diventa un sistema operativo semantico per lo sviluppo software assistito dall’AI.

Questo articolo non vuole proporre una nuova metodologia, né suggerire che l’AI sostituirà la progettazione software. Al contrario, l’obiettivo è mostrare come la generazione automatica di codice renda ancora più centrale il problema della conoscenza. Prossimamente tratterò alcuni aspetti specifici di questa trasformazione: il ruolo dell’ambiguità nei sistemi AI-driven, il DDD come sistema semantico, la living documentation come memoria architetturale e le fitness function come meccanismo di governance automatica.