[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f3f5uwe9b0i6b0":3,"$f3596me20t39pz":29},{"data":4},[5],{"id":6,"slug":7,"locale":8,"type":9,"title":10,"subtitle":11,"summary":12,"body":13,"primary_topic":14,"knowledge_status":15,"practical_validation":16,"workflow_status":17,"author_id":18,"published_at":19,"updated_at":19,"review_due_at":20,"canonical_url":20,"seo_title":20,"seo_description":20,"hero_asset_id":20,"reading_time":20,"version":21,"technology_versions":22,"review_frequency_days":20,"parent_content_id":23,"sort_in_parent":24,"hub_entry_status":25,"content_blocks":26,"hero_alt_text":20,"hero_caption":20,"hero_credit":20,"publication_scope":27,"access_level":28},"5ed9e4cd-d580-4b70-bdc4-270cbe8d1813","introduzione-domain-driven-design","it","CAPSULE","Introduzione al Domain-Driven Design","Progettare il software partendo dal dominio","Il Domain-Driven Design non parte da framework, database o microservizi, ma dal problema che il software deve rappresentare. Un'introduzione ai principi fondamentali del DDD: Ubiquitous Language, Bounded Context, Entity, Value Object, Aggregate, Domain Event e isolamento del dominio dall'infrastruttura.","Domain-Driven Design: progettare il software partendo dal dominio\n\nQuando iniziamo a progettare un nuovo sistema software siamo naturalmente portati a parlare subito di framework, database, API, microservizi e tecnologie.\n\nIl Domain-Driven Design, spesso abbreviato in DDD, propone di ribaltare questa prospettiva: prima della tecnologia viene il dominio, cioè il problema reale che il software deve comprendere e rappresentare.\n\nDDD non è quindi un framework né un'architettura specifica. È prima di tutto un approccio alla progettazione del software che mette al centro la conoscenza del dominio e la collaborazione tra chi sviluppa il sistema e chi conosce realmente il contesto in cui quel sistema dovrà operare.\n\n\nComprendere il dominio prima di progettare la soluzione\n\nUno degli errori più comuni nella progettazione software consiste nel tradurre troppo rapidamente un problema reale in concetti tecnici.\n\nSi osserva un processo e si pensa subito a tabelle, form, controller, servizi, API o code di messaggi.\n\nIl Domain-Driven Design suggerisce invece di ritardare queste decisioni e di comprendere prima ciò che realmente accade nel dominio.\n\nOccorre individuare gli attori coinvolti, le attività svolte, le decisioni prese, le regole applicate, le eccezioni possibili, gli eventi significativi e le informazioni necessarie per completare i processi.\n\nQuesto lavoro richiede un confronto continuo con i Domain Expert, cioè con le persone che conoscono realmente il dominio.\n\nLo sviluppatore non deve limitarsi a ricevere requisiti da implementare. Deve contribuire alla costruzione di un modello condiviso del problema.\n\n\nUbiquitous Language: un linguaggio condiviso\n\nUno dei concetti fondamentali del Domain-Driven Design è la Ubiquitous Language.\n\nSi tratta di un linguaggio condiviso tra sviluppatori, analisti ed esperti del dominio.\n\nI termini utilizzati per descrivere il business dovrebbero, quando possibile, essere gli stessi utilizzati nel modello software.\n\nSe nel dominio esistono concetti come Ordine, Prenotazione, Paziente, Richiesta, Prestazione o Revisione, il software dovrebbe utilizzare gli stessi termini con lo stesso significato.\n\nIn questo modo si riduce la continua traduzione tra linguaggio tecnico e linguaggio del business.\n\nLa Ubiquitous Language non è statica.\n\nMan mano che cresce la conoscenza del dominio, alcuni termini possono essere corretti, sostituiti o raffinati.\n\nIl linguaggio e il modello software devono quindi evolvere insieme.\n\nL'obiettivo non è semplicemente rappresentare dati, ma incorporare nel software la conoscenza del dominio.\n\n\nIl modello come rappresentazione della conoscenza\n\nNel DDD il modello non deve essere considerato soltanto come una struttura dati.\n\nUn buon modello deve rappresentare concetti, comportamenti, regole e vincoli del dominio.\n\nQuesto significa evitare, quando possibile, oggetti che siano semplicemente contenitori di proprietà modificabili liberamente dall'esterno.\n\nInvece di avere soltanto operazioni generiche come:\n\nsetStato(...)\nsetCampo(...)\nupdate(...)\n\nil modello dovrebbe poter esprimere operazioni significative per il dominio, ad esempio:\n\nordine.conferma()\nprenotazione.annulla()\nrichiesta.inviaInRevisione()\npaziente.fondiCon(...)\n\nIn questo modo il codice utilizza lo stesso linguaggio del dominio e le regole diventano più esplicite.\n\n\nDomain e Subdomain\n\nUn'organizzazione complessa contiene normalmente più aree di conoscenza e responsabilità.\n\nIl dominio complessivo può quindi essere suddiviso in Subdomain.\n\nNon tutte le parti hanno lo stesso valore strategico.\n\nAlcuni subdomain rappresentano ciò che distingue realmente l'organizzazione e costituiscono il Core Domain.\n\nAltri sono necessari ma più generici o di supporto.\n\nQuesta distinzione aiuta a decidere dove investire maggiormente nella modellazione e dove invece utilizzare soluzioni più semplici o standardizzate.\n\n\nBounded Context\n\nQuando il dominio cresce, difficilmente un unico modello riesce a rappresentarlo correttamente.\n\nIl Domain-Driven Design introduce quindi il concetto di Bounded Context.\n\nUn Bounded Context è un confine all'interno del quale termini, regole e modelli assumono un significato preciso.\n\nLa stessa parola può avere significati differenti in contesti differenti.\n\nIl concetto di Cliente, ad esempio, potrebbe assumere caratteristiche diverse nel contesto commerciale, nel contesto amministrativo e nel contesto dell'assistenza.\n\nNon è necessario creare un modello universale che soddisfi contemporaneamente tutti questi significati.\n\nOgni Bounded Context può possedere il proprio modello coerente.\n\n\nDDD non significa microservizi\n\nUn errore frequente consiste nell'identificare automaticamente un Bounded Context con un microservizio.\n\nNon sono la stessa cosa.\n\nIl Bounded Context è prima di tutto un confine concettuale e organizzativo del modello.\n\nPuò essere implementato come modulo di un monolite, come applicazione indipendente oppure come servizio distribuito.\n\nLa scelta tecnologica viene dopo la comprensione del dominio.\n\nUn sistema può quindi applicare perfettamente il Domain-Driven Design senza utilizzare microservizi.\n\n\nContext Map\n\nI Bounded Context non vivono necessariamente isolati.\n\nDevono spesso scambiarsi informazioni e collaborare.\n\nLa Context Map descrive le relazioni tra i diversi contesti.\n\nQueste relazioni possono assumere forme differenti.\n\nUn contesto può esporre un'API, due contesti possono condividere una piccola parte del modello, oppure un contesto può introdurre uno strato di protezione per evitare che il modello di un sistema esterno condizioni il proprio.\n\nL'obiettivo è rendere esplicite le dipendenze invece di lasciarle emergere accidentalmente nel codice.\n\n\nAnticorruption Layer\n\nQuando un sistema deve integrarsi con un altro sistema che utilizza concetti o modelli differenti, il DDD propone il pattern Anticorruption Layer.\n\nQuesto strato traduce il modello esterno nel linguaggio del proprio Bounded Context.\n\nIn questo modo il dominio interno non viene contaminato dalle strutture, dalle terminologie o dalle decisioni progettuali del sistema esterno.\n\nÈ un principio particolarmente utile nelle integrazioni con sistemi legacy, prodotti di terze parti o piattaforme appartenenti ad altre organizzazioni.\n\n\nEntity\n\nUna Entity è un oggetto del dominio caratterizzato principalmente dalla propria identità.\n\nDue Entity possono avere gli stessi valori e continuare a rappresentare oggetti differenti.\n\nUn ordine, un paziente, una pratica o una prenotazione possono cambiare molti dei propri attributi nel tempo continuando però a rappresentare la stessa entità.\n\nL'identità accompagna quindi l'oggetto durante il suo ciclo di vita.\n\n\nValue Object\n\nUn Value Object è invece definito dai propri valori e non da un'identità.\n\nDue Value Object con gli stessi valori possono essere considerati equivalenti.\n\nEsempi tipici possono essere un intervallo temporale, una quantità, un indirizzo o un valore monetario, a seconda del dominio.\n\nQuando possibile, i Value Object sono immutabili.\n\nL'immutabilità rende il modello più semplice da comprendere, utilizzare e testare.\n\n\nAggregate e Aggregate Root\n\nUn Aggregate è un insieme di oggetti del dominio gestito come una singola unità di consistenza.\n\nAll'interno dell'Aggregate esiste un oggetto principale chiamato Aggregate Root.\n\nLe modifiche agli oggetti interni dovrebbero passare attraverso l'Aggregate Root.\n\nQuesto permette di proteggere le invarianti del dominio.\n\nUn'invariante è una regola che deve essere sempre rispettata affinché lo stato del sistema sia valido.\n\nL'Aggregate non serve quindi semplicemente a raggruppare oggetti.\n\nServe soprattutto a stabilire un confine entro il quale garantire la consistenza delle regole del dominio.\n\n\nProteggere le invarianti\n\nUn modello dovrebbe impedire la creazione di stati che non hanno significato per il dominio.\n\nSe una richiesta può essere pubblicata soltanto dopo una revisione, il modello dovrebbe impedire il passaggio diretto da bozza a pubblicato.\n\nSe una prenotazione annullata non può essere nuovamente confermata, questa regola dovrebbe essere protetta dal modello.\n\nL'obiettivo è spostare le regole vicino agli oggetti che possiedono la conoscenza necessaria per applicarle.\n\n\nTell, Don't Ask\n\nQuesto approccio porta naturalmente al principio Tell, Don't Ask.\n\nInvece di interrogare continuamente un oggetto, estrarre il suo stato, prendere una decisione all'esterno e poi modificarlo, è preferibile chiedere all'oggetto di eseguire un'operazione significativa.\n\nInvece di:\n\nleggere stato\nverificare stato\nmodificare stato\n\nsi preferisce qualcosa come:\n\nrichiesta.pubblica()\n\nL'oggetto stesso verifica se l'operazione è consentita e protegge le proprie invarianti.\n\n\nDomain Service\n\nNon tutte le operazioni del dominio appartengono naturalmente a una Entity o a un Value Object.\n\nQuando una responsabilità rappresenta realmente un comportamento del dominio ma non può essere assegnata correttamente a un singolo oggetto, può essere introdotto un Domain Service.\n\nUn Domain Service non dovrebbe però diventare un contenitore generico nel quale spostare tutta la logica.\n\nDeve rappresentare un concetto o un'operazione realmente appartenente al dominio.\n\n\nRepository\n\nIl Repository rappresenta l'astrazione attraverso cui il dominio recupera e conserva gli Aggregate.\n\nIl dominio non dovrebbe sapere se i dati vengono memorizzati in PostgreSQL, Oracle, MongoDB, un file o un servizio remoto.\n\nIl Repository permette quindi di esprimere operazioni in termini vicini al dominio senza introdurre nel modello i dettagli della persistenza.\n\n\nFactory\n\nLa creazione di un oggetto del dominio può diventare complessa.\n\nQuando la costruzione di una Entity o di un Aggregate richiede diverse regole, verifiche o dipendenze, può essere utile introdurre una Factory.\n\nLa Factory incapsula il processo di creazione e garantisce che l'oggetto venga prodotto già in uno stato valido.\n\n\nDomain Event\n\nUn Domain Event rappresenta qualcosa di significativo che è già avvenuto nel dominio.\n\nEsempi potrebbero essere:\n\nOrdineConfermato\nPrenotazioneAnnullata\nPazienteRegistrato\nRichiestaPubblicata\n\nUn Domain Event descrive un fatto del dominio, non semplicemente un dettaglio tecnico.\n\nGli eventi possono consentire ad altre parti del sistema di reagire senza introdurre un accoppiamento diretto tra gli oggetti coinvolti.\n\n\nDomain Event non significa necessariamente messaging\n\nLa presenza di Domain Event non obbliga a utilizzare un message broker.\n\nUn evento del dominio può essere gestito anche internamente alla stessa applicazione.\n\nSoltanto quando esistono reali esigenze di integrazione, asincronia, affidabilità o distribuzione può essere opportuno introdurre infrastrutture di messaging.\n\nAnche in questo caso la tecnologia dovrebbe essere una conseguenza del requisito e non il punto di partenza.\n\n\nSeparare dominio e infrastruttura\n\nUno dei principi più importanti del DDD consiste nel mantenere il dominio il più possibile indipendente dalla tecnologia.\n\nDatabase, framework, API, interfacce utente e sistemi esterni sono necessari, ma non dovrebbero determinare la struttura del modello.\n\nIl dominio rappresenta la conoscenza e le regole dell'organizzazione.\n\nL'infrastruttura deve supportarlo.\n\n\nArchitettura esagonale\n\nL'Hexagonal Architecture, o Ports and Adapters, è particolarmente coerente con questa impostazione.\n\nIl dominio rimane al centro.\n\nLe interazioni con il mondo esterno avvengono attraverso porte e adapter.\n\nUna porta descrive ciò di cui il dominio ha bisogno o ciò che rende disponibile.\n\nUn adapter implementa l'integrazione concreta con una determinata tecnologia.\n\nL'interfaccia Web può essere un adapter.\n\nIl database può essere un adapter.\n\nUn sistema esterno può essere un adapter.\n\nUn message broker può essere un adapter.\n\nIl dominio non deve dipendere direttamente da nessuno di essi.\n\n\nPersistence Ignorance\n\nDa questa separazione deriva il principio della Persistence Ignorance.\n\nGli oggetti del dominio non dovrebbero essere progettati principalmente in funzione del modo in cui vengono salvati sul database.\n\nLa persistenza è necessaria, ma dovrebbe restare un dettaglio infrastrutturale.\n\nQuesto permette al modello di rappresentare meglio il problema reale e riduce l'accoppiamento con una particolare tecnologia.\n\n\nDDD e complessità\n\nDomain-Driven Design non significa introdurre più complessità.\n\nAl contrario, il suo obiettivo è gestire consapevolmente la complessità che appartiene realmente al dominio.\n\nNon tutti i sistemi hanno bisogno dello stesso livello di modellazione.\n\nPer applicazioni semplicemente CRUD o con poche regole di business, un modello sofisticato potrebbe rappresentare un costo inutile.\n\nDDD diventa particolarmente utile quando il dominio contiene regole articolate, concetti ambigui, processi complessi e conoscenza che deve essere resa esplicita nel software.\n\n\nEvitare l'over-engineering\n\nEntity, Value Object, Aggregate, Repository, Factory e Domain Event non devono essere utilizzati soltanto perché fanno parte del vocabolario DDD.\n\nOgni astrazione introduce un costo.\n\nUn pattern dovrebbe essere introdotto quando risolve un problema reale del modello.\n\nLa qualità di un'architettura non dipende dal numero di pattern presenti.\n\nDipende dalla capacità del sistema di rappresentare correttamente il dominio e di evolvere insieme ad esso.\n\n\nModello e software devono evolvere\n\nLa prima rappresentazione di un dominio raramente è quella definitiva.\n\nNuove conversazioni con gli esperti fanno emergere regole che prima non erano conosciute.\n\nTermini apparentemente equivalenti possono rivelarsi differenti.\n\nAlcuni concetti possono essere eliminati o suddivisi.\n\nIl modello deve quindi essere continuamente raffinato.\n\nIl refactoring non riguarda soltanto il codice.\n\nNel Domain-Driven Design riguarda anche la conoscenza del dominio.\n\n\nIl valore del feedback\n\nUna buona progettazione non deve isolarsi dagli utenti alla ricerca di un modello perfetto.\n\nIl feedback reale è parte del processo di apprendimento.\n\nPrototipi, piccoli esperimenti e rilasci progressivi permettono di verificare se il modello rappresenta realmente il problema.\n\nL'obiettivo non è costruire immediatamente l'architettura perfetta, ma migliorare continuamente la comprensione del dominio.\n\n\nDDD come processo continuo\n\nIl Domain-Driven Design può essere sintetizzato come un processo continuo:\n\ncomprendere → nominare → modellare → isolare → verificare → evolvere.\n\nComprendere significa studiare il problema reale.\n\nNominare significa costruire una Ubiquitous Language.\n\nModellare significa trasformare la conoscenza in concetti e comportamenti coerenti.\n\nIsolare significa definire confini chiari tra domini, contesti e infrastruttura.\n\nVerificare significa confrontare continuamente il modello con la realtà.\n\nEvolvere significa accettare che il modello debba cambiare insieme alla comprensione del dominio.\n\n\nConclusione\n\nIl Domain-Driven Design non è una collezione di pattern da applicare meccanicamente.\n\nÈ soprattutto un modo di mettere la conoscenza del dominio al centro delle decisioni progettuali.\n\nFramework, database, API, microservizi e tecnologie rimangono strumenti importanti, ma vengono scelti dopo aver compreso il problema da risolvere.\n\nQuando il dominio è complesso, questa inversione di prospettiva può fare una differenza sostanziale.\n\nIl software smette di essere soltanto una struttura tecnica che memorizza e trasferisce dati e diventa una rappresentazione esplicita della conoscenza, delle regole e dei processi dell'organizzazione.","58ba728e-da9d-409d-a6c7-31325e3773a8","NOTE","NOT_PERFORMED","PUBLISHED","794a9185-136c-4415-ab23-cd144eb5870e","2026-08-18T15:31:01.169Z",null,1,{},"ca42243d-0981-4c29-a091-167d7c2d6df3",0,"IN_PROGRESS",[],"PORTAL","ANONYMOUS",{"primaryTopic":30,"technologies":34,"sources":35,"secondaryTopics":45,"tags":46},[31],{"id":14,"name":32,"slug":33},"Software Architecture","software-architecture",[],[36],{"source_id":37},{"id":38,"type":39,"title":40,"author":41,"publisher":42,"edition":43,"url":20,"license_notes":44},"c0c5275f-5d1e-4d27-9bc7-64d29b159ac2","BOOK","JavaScript Domain-Driven Design","Philipp Fehre","Packt Publishing","2015","Approfondimento personale basato anche sullo studio della fonte; nessuna riproduzione sostanziale del testo originale.",[],[]]