Domain-driven design: differenze tra le versioni

Versione delle 10:49, 22 mag 2015

Versione attuale delle 10:33, 14 gen 2025

(30 versioni intermedie di 21 utenti non mostrate)

Riga 1:

'''Domain-driven design''' ('''DDD''') è un approccio delloalla sviluppoprogettazione del software che risolvepunta problemia complessiriprodurre connettendoa l'implementazionelivello addel software un modellodominio inapplicativo, evoluzione.<refbasandosi name="definition">{{Citasull'input pubblicazione|url=degli esperti di http://wwwquel dominio.domaindrivendesign.org/ |titolo=Il DomainDDD drivenpunta design}}.</ref>a suddividere Lei premessesistemi delin ___domain-drivencontesti sonodelimitati, leciascuno seguenti:con il proprio modello, piuttosto che a progettare un singolo modello onnicomprensivo.

* Puntando il focus primario del progetto sui domini delle entità e la loro logica.

* Basare il design sulle entità di dominio.

* Iniziare una creativa collaborazione tra tecnici ed esperti di dominio per definire in maniera iterativa un modello concettuale che possa essere applicato ai particolari problemi del caso.

Seguendo i principi del ___domain-driven design la struttura e il linguaggio del software dovrebbero corrispondere alla struttura e al linguaggio del dominio. Ad esempio, in una software che si occupa di gestire una cantina vinicola possono esistere classi come "bottiglia" oppure "mosto" e metodi come "applica etichetta" oppure "imbottiglia".

Il termine è stato introdotto da [[Eric Evans (technologist)|Eric Evans]] nel libro dallo stesso titolo.<ref name="book.evans">{{Cita libro|titolo=Domain-Driven Design: Tackling Complexity in the Heart of Software |cognome=Evans |nome=Eric |wkautore=Eric Evans (technologist) |anno=2004 |editore=Addison-Wesley |isbn=978-0-321-12521-7|accesso=12 agosto 2012 |url=http://www.domaindrivendesign.org/books/evans_2003}}.</ref>

I processi DDD si basano su tre principi cardine:

==Definizioni fondamentali==

* focalizzare il progetto attorno al dominio e alla logica di dominio;

;Dominio: Un contesto di conoscenza ([[Ontologia (informatica)|ontologia]]), influenza, o attività. L'area in cui l'utente lavora con il software è il dominio dello stesso.

* basare la progettazione di sistemi complessi sui modelli del dominio;

;Modello: Un sistema di astrazione che descrive specifici aspetti del dominio e che può essere usato per risolvere problematiche relative alla definizione del dominio.

* mantenere una collaborazione tra tecnici ed esperti di dominio per rifinire in maniera iterativa modelli concettuali che possano essere applicati ai problemi del dominio.<ref>{{Cita web|url=https://blog.airbrake.io/blog/software-design/___domain-driven-design|titolo=Domain-Driven Design: What is it and how do you use it?|sito=blog.airbrake.io|lingua=en|accesso=18 ottobre 2024}}</ref>

;Ubiquitous Language: Un set di termini create attorno al modello di dominio utilizzati dal team per indirizzare e contestualizzare i problemi da risolvere durante l'implementazione.

;Contesto: L'ambiente in cui un determinato termine assume un determinato significato.

Il termine "Domain-driven design" è stato coniato da [[Eric Evans (technologist)|Eric Evans]] nel 2003 nel libro omonimo.<ref>{{Cita libro|nome=Eric|cognome=Evans|titolo=Domain-driven design: tackling complexity in the heart of software|anno=2004|url=https://archive.org/details/domaindrivendesi0000evan|data=2004|editore=Addison-Wesley|ISBN=978-0-321-12521-7}}</ref>

== Definizioni fondamentali ==

;Dominio: UnIl contesto di conoscenza ([[Ontologia (informatica)|ontologia]]), influenza, o attività. L'area, in cui l'utenteè lavora coninserito il software, èe ilsulle dominioquali dellologiche stessoil software lavora.

;Modello: Un sistema di astrazioneastrazioni che descrive specifici aspetti del dominio, e che può essere usato per risolvere problematicheproblemi relativerelativi alla definizione delal dominio.

;Ubiquitous language: Una terminologia comune basata sul dominio e condivisa tra tutto il team che si occupa della progettazione, e che è utilizzata in tutte le attività che coinvolgono il software.

== Strategie nel ___domain-driven design ==

[[File:Maintaining Model Integrity.png|thumb|I patterns e le relazioni fra essi, nel progettare del software ___domain-driven]]

Idealmente, è preferibile avere un singolo modello unificato. Anche se questo è un nobile proposito, nella realtà ci dobbiamo tipicamente scontrare con più modelli che coesistono. èÈ utile integrare questa assunzione e lavorare con essa.

Le strategie nel design sono una serie di principi atti a mantenere l'integrità del modello, e che portano a sviluppare il modello di dominio e di interazione tra i vari modelli.

=== Bounded context ===

=== Il contesto come delimitato e definito ===

In progetti di grandi dimensioni molti modelli devono interagire tra loro. È facile che la complessità e la molteplicità di interazioni portino a problemi tecnici, di organizzazione e di comunicazione. La strategia del ''bounded context'' serve a gestire la complessità di un dominio suddividendolo in aree delimitate e definite, ciascuna con i propri modelli, la propria logica e la propria terminologia. Questo promuove l'indipendenza dello sviluppo all'interno dei singoli contesti, minimizzando i rischi di interferenze tra di loro.<ref>{{Cita web|url=https://ddd-practitioners.com/2023/03/07/the-difference-between-domains-subdomains-and-bounded-contexts/|titolo=The difference between domains, subdomains and bounded contexts|autore=Premanand Chandrasekaran|sito=Domain-driven Design: A Practitioner's Guide|data=7 marzo 2023|lingua=en|accesso=18 ottobre 2024}}</ref>

In progetti di grandi dimensioni molti modelli devono interagire tra loro. Spesso quando il codice che opera su diversi modelli deve essere integrato il lavoro diventa difficile facendo emergere bugs e rendendo il progetto difficile da comprendere e manutenere. La comunicazione tra i membri del team diventa confusa. Diventa quindi poco chiaro a quale contesto un modello è applicato.

I bounded context servono anche a risolvere il problema della [[polisemia]], cioè la proprietà per una parola di assumere più significati: il contesto in cui un appare un termine determina il suo significato. Ad esempio il "prezzo" per un reparto vendite è una cosa diversa dal "prezzo" per un reparto acquisti. In un approccio DDD la soluzione al problema è segregare ciascun "prezzo" nel suo bounded context, in maniera da limitare le occasioni di fraintendimento, sia nello sviluppo del software concreto, sia nella comunicazione all'interno del progetto.<ref>{{Cita web|url=https://martinfowler.com/bliki/BoundedContext.html|titolo=bliki: Bounded Context|sito=martinfowler.com|accesso=18 ottobre 2024}}</ref>

La miglior soluzione è definire in maniera esplicita il contesto al quale un modello è applicato. Inoltre è utile esplicitare i confini a livello di organizzazione del team, per chiarire in quali punti dell'applicazione si usa un modello e soprattutto riversare queste assunzioni nell'implementazione. Più di tutto è fondamentale mantenere il modello coerente all'interno dei limiti posti, non facendosi influenzare e confondere dall'ecosistema che sta intorno.

=== Continuous integration ===

Quando più persone lavorano alloall'interno dello stesso contesto definito, c'è unafacile forteche tendenzanascano ainterpretazioni frammentarecontraddittorie ildegli stessi modellomodelli. PiùIl grossoproblema ècresce ilcon l'aumentare di dimensione del team, piùma grossonon è ilescluso problema,che emerga anche unin team dipoco trenumerosi. oAllo quattrostesso personetempo, puòframmentare incontrareil problemi. Inoltre frammentaredominio in manieratroppi eccessiva il contestocontesti porta aalla problemiperdita di nell'integrazione e nelladi coerenza delle informazioni.

La soluzione è istituire un processo di ''[[Continuous Integration|continuous integration]],'' sia del codice, con l'integrazione frequente delle nuove modifiche con annessi step di testing, sia delle informazioni, con l'esercizio costante dell'ubiquitous language all'interno del team, in modo da mantenere una visione condivisa del modello man mano che la sua concezione evolve nella mente dei singoli membri del team.<ref>{{Cita web|url=http://ddd.fed.wiki.org/view/continuous-integration|titolo=continuous integration|sito=ddd.fed.wiki.org|accesso=18 ottobre 2024}}</ref>

La miglior soluzione è istituire un processo frequente di merging del codice con uno step di testing. un Institute a process of merging all code and other implementation artifacts frequently, with automated tests to flag fragmentation quickly. In questo modo si esercita una costante condivisione della concezione del modello che può evolvere liberamente con i contributi singolari degli sviluppatori.

=== Context map ===

Line 35 ⟶ 38:

La soluzione è definire ogni modello che esiste nel progetto e definirne i limiti. Questo include modelli impliciti di sotto progetti non object-oriented. Trovare il nome di ogni contesto delimitato, e renderlo parte del linguaggio specifico del dominio. Descrivere i punti di contatto tra i modelli, esplicitando le traduzioni che occorrono nella comunicazione ed evidenziando le condivisioni di informazioni.

== Costruire le basiArtefatti del DDD ==

Nel libro ''Domain-Driven Design'', che è orientato a descrivere sistemi orientati agli oggetti, vengono introdotti una serie di artefatti per esprimere modelli di dominio nell'ambito di un processo di progettazione ___domain-driven:

Nel libro ''Domain-Driven Design''<ref name="book.evans">{{Cita libro |titolo=Domain-Driven Design: Tackling Complexity in the Heart of Software |cognome=Evans |nome=Eric |anno=2004 |editore=Addison-Wesley |isbn=978-032-112521-7|accessdate=August 12, 2012 |url=http://www.domaindrivendesign.org/books/evans_2003}}.</ref>, vengono introdotti una serie di concetti chiave e pratiche, come il significato ''ubiquitous language'' cioè un linguaggio unificato creato dagli esperti del dominio che viene usato per descrivere i requisiti di sistema, che inoltre si adatta all'utilizzo da parte di vari attori quali utenti, produttori e sviluppatori. Il libro è fortemente orientato a descrivere lo strato di dominio in un sistema orientato agli oggetti con un'architettura a multistrati. Nel DDD, esistono artefatti per esprimere, creare, e recuperare modelli di dominio:

;Entity: Un oggetto che non è definito dai suoi attributi, ma piuttosto dalla sua identità. PerAd esempio, lain maggioruna partebiblioteca delledove compagnieci aereeinteressa distinguonoidentificare inciascuna modocopia univocoa ognidisposizione sediledegli suutenti, ognii volo.libro Ogniè sedileuna èentity: un'entitànonostante inil questosuo contesto.stato Tuttavia(disponibile, Southwestin Airlinesprestito, EasyJetsmarrito, eetc.) Ryanairo nonla distinguonosua tracollocazione tuttisu iscaffale sedili;possano Tutti i sedili sono uguali. In questo contestocambiare, ilquel sedilelibro è inrimane realtàfisicamente unlo valuestesso objectoggetto.

;Value Objectobject: Un oggetto che ha una serie di attributi ma non ha identità concettuale. DevonoI value object devono essere trattati come immutabileoggetti immutabili. Per esempio quando le persone si scambiano [[Banconote in euro|banconote da uncinque dollaroeuro]], cheessi insono generesolo noninteressati distinguonoal travalore unnominale unicodella prototipo;banconota, sononon soloalla preoccupatisingola peridentità ildelle valorebanconote nominale della banconotascambiate. In questo contesto, le banconote da uncinque dollaroeuro sono un value object.: se la persona A ha una banconota da cinque Tuttaviaeuro, e la Federalpersona ReserveB potrebbeha essereuna preoccupatabanconota perda ognicinque, pagamentoe unico;le due persone se le scambiano, il loro stato di "possessori di una banconota da cinque euro" non è cambiato, e non cambia indipendentemente da quante volte avviene lo scambio.: In questoun contesto diverso, ognicome prototipoper esempio un sistema bancario, potrebbe essere necessario identificare la singola banconota attraverso il suo [[Numero di serie|numero seriale]]: in questo contesto la banconota è un'entità.', è c'è differenza se un [[sportello automatico]] fornisce ad un utente la banconota con il numero di serie <code>1234</code> rispetto a quella con numero di serie <code>1235</code>.

;Aggregate: Una collezione di oggetti che sono legati insieme da un'entità padre, altrimenti nota come una''aggregate radice di aggregatoroot''. LaL'entità radice di aggregazione garantisceincapsula la complessità e mantiene la consistenza dei cambiamenti compiuti all'interno dell'aggregato, proibendo ad oggetti esterni di detenere i riferimenti ai suoi membri interni.: Per esempio, quandonel sicontesto di un reparto vendite un ordine può essere composto guidada unapiù macchinaprodotti, none ciha siun totale che deve preoccuparesempre dicorrispondere muoverealla lesomma ruotedei inprezzi avanti,dei tenereprodotti ilinclusi motorenell'ordine. inÈ combustioneutile attraversoesprimere l'accensioneordine ecome aggregate, in modo da poter garantire la consistenza del combustibile,totale eccconsentendo .;l'accesso siai staprodotti semplicementesolo guidandotramite l'autoordine. InL'ordine, questoaggregate contestoroot, laha macchinail ècompito undi aggregatoricevere le richieste di diversimodifica altridei oggettiprodotti eprovenienti servedall'esterno comedell'aggregate, radicee aggregatadi permodificare tuttiil glitotale altridi sistemiconseguenza.

;Domain Eventevent: Un oggettoevento di dominio è un oggetto che definiscerappresenta un evento (qualcosa che accade).ha Uncausato eventouna modifica dello stato di dominiouna èo più entità. Ad esempio, in una biblioteca, un prestito può essere un evento di assolutadominio, importanzain perquanto glirappresenta espertiil cambio di dominiostato di un libro da "disponibile" a "in prestito".

;Service: Quando un'operazione non appartiene naturalmente a nessun oggetto forzare la sua appartenenza ad un oggetto distorce la coerenza del modello oppure causa un proliferare di oggetti astratti privi di significato di dominio. Queste operazioni devono essere definite in un ''service'', un componente che ha come unica responsabilità lo svolgimento di queste operazioni. Ad esempio, in un sistema [[ecommerce]], il calcolo delle spese di spedizione è un ottimo candidato per essere implementato in un ''service.''

;Service: Quando un'operazione non appartiene logicamente a nessun oggetto. Quindi è possibile implementare queste operazioni nel settore dei servizi.

;Repository: I repository sono servizi che espongono un'interfaccia per il recupero di oggetti di dominio, astraendo il database sottostante e fornendo metodi che seguono le esigenze del dominio e che sono coerenti con l'ubiquitous language. Ad esempio, un repository di libri per una biblioteca potrebbe esporre i metodi <code>libriInPrestito</code> e <code>libriDisponibili</code> .

;Repository: Metodi per il recupero di oggetti di dominio delegati da un oggetto repository specializzato tale che l'implementazione di storage alternativi sia facile.

;Factory: Le factory sono oggetti all'interno del dominio che hanno il compito astrarre la creazione di oggetti o aggregati complessi e difficili da costruire, rendendo più facile creare questi oggetti ed evitando di rendere i client che eseguono la creazione troppo dipendenti dalla struttura interna e dalle regole di questi oggetti.

;Factory: Metodi per la creazione di oggetti di dominio che delegano ad un oggetto la loro creazione così da facilitare le implementazioni alternative.

=== Svantaggi ===

Al fine di mantenere il modello come un costrutto del linguaggio puro e utile, il team deve tipicamente implementare l'isolamento con grande attenzione e prestare attenzione all'incapsulamento all'interno del modello di dominio. Di conseguenza, un sistema costruito attraverso il Domain Driven Design può essere oneroso in termini di costo di sviluppo.

Quindi un sistema batobasato sul Domain Driven Design ha un costo relativamente alto. Il Domain Driven Design offre certamente numerosi vantaggi tecnici, ad esempio la manutenibilità, Microsoft raccomanda comunque di applicarlo solo ai domini complessi in cui il modello e i processi linguistici offrono evidenti vantaggi nella comunicazione di informazioni complesse, e nella formulazione di una visione comune del dominio.

== Note ==

<references />

==Vedi ancheVoci correlate ==

* [[Semantica]]

* [[Rappresentazione della conoscenza]]

Line 59 ⟶ 62:

* [[Rete semantica]]

== Collegamenti esterni ==

* {{Cita pubblicazione|autore=Eric Evans|titolo=Domain Driven Design, Definitions and Pattern Summaries|url=https://www.domainlanguage.com/wp-content/uploads/2016/05/DDD_Reference_2015-03.pdf}}

* {{Cita pubblicazione|url= http://www.infoq.com/presentations/model-to-work-evans |nome= Eric |cognome= Evans |editore= InfoQ |tipo= presentation |titolo= Domain Driven Design – Putting the Model to Work}}

* {{Cita pubblicazione|url= http://www.infoq.com/presentations/strategic-design-evans |nome= Eric |cognome= Evans | author-mask = 3 |editore= InfoQ |tipo= presentation |titolo= Domain Driven Design – Strategic Design}}

* {{Cita pubblicazione|url= http://www.infoq.com/interviews/jimmy-nilsson-___domain-driven-design |nome= James ‘Jimmy’'Jimmy' |cognome= Nilsson |titolo= Domain Driven Design |editore= InfoQ}}

* {{Cita pubblicazione |url= http://tech.groups.yahoo.com/group/domaindrivendesign/ |titolo= Domain-Driven Design |tipo= forum |editore= Yahoo! |urlmorto= sì |urlarchivio= https://web.archive.org/web/20090615224147/http://tech.groups.yahoo.com/group/domaindrivendesign/ }}

* {{Cita pubblicazione |url= http://www.methodsandtools.com/archive/archive.phpisp?id=97 |titolo= An Introduction to Domain Driven Design |editore= Methods & tools |urlmorto= sì }}

* {{Cita pubblicazione |url= http://codebetter.com/blogs/gregyoung/archive/2010/02/16/cqrs-task-based-uis-event-sourcing-agh.aspx |nome= Gregory ‘Greg’ |cognome= Young |titolo= CQRS, Task Based UIs, Event Sourcing agh! |data= 16 febbraio 2010 |editore= Code better |tipo= [[World Wide Web log]] |accesso= 19 maggio 2015 |urlarchivio= https://web.archive.org/web/20101121115055/http://codebetter.com/blogs/gregyoung/archive/2010/02/16/cqrs-task-based-uis-event-sourcing-agh.aspx |urlmorto= sì }}

* {{Cita pubblicazione |url= http://blog.cleverlabs.com/2010/11/___domain-driven-design-that-works.html |nome= Jon |cognome= Jenkins |editore= Clever Labs |titolo= Domain‐driven design that works |data=November 2010novembre 2010 |tipo= World Wide Web log |accesso= 19 maggio 2015 |urlarchivio= https://web.archive.org/web/20110812142502/http://blog.cleverlabs.com/2010/11/___domain-driven-design-that-works.html |urlmorto= sì }}: Domain Driven Design's importance in the business.

* {{Cita pubblicazione|url= http://www.udidahan.com/2009/12/09/clarified-cqrs/ |nome= Udi |cognome= Dahan |titolo= Clarified CQRS |data= 9 dicembre 2009}}: how it relates to other patterns]

* {{Cita pubblicazione|url= http://www.infoq.com/articles/haywood-ddd-no |nome= Dan |cognome= Haywood |tipo= interview |editore= InfoQ |titolo= Domain Driven Design using Naked Objects}}