Domain-driven design: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
Nessun oggetto della modifica |
Aggiungi 1 libro per la Wikipedia:Verificabilità (20250110)) #IABot (v2.0.9.5) (GreenC bot |
||
| (42 versioni intermedie di 26 utenti non mostrate) | |||
Riga 1:
'''Domain-driven design''' ('''DDD''') è un approccio
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".
I processi DDD si basano su tre principi cardine:
==Asserzioni 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>
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>
▲
▲
;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|
Idealmente, è preferibile avere un singolo modello unificato. Anche se questo è un nobile proposito, nella realtà ci dobbiamo tipicamente scontrare con più modelli che coesistono.
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 ===
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>
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>
=== Continuous integration ===
Quando più persone lavorano all'interno dello stesso contesto è facile che nascano interpretazioni contraddittorie degli stessi modelli. Il problema cresce con l'aumentare di dimensione del team, ma non è escluso che emerga anche in team poco numerosi. Allo stesso tempo, frammentare il dominio in troppi contesti porta alla perdita di integrazione e di 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>
=== Context map ===
Un singolo contesto delimitato porta ad una serie di problemi in assenza di una visione globale. Il contesto di altri modelli potrebbe essere ancora vago e non completo.
Gli sviluppatori degli altri team potrebbero non essere consapevoli del dominio in cui il contesto opera, quindi la modifica ad un contesto si rende complicata a fronte di confini non ben definiti. Quando interconnessioni tra contesti si rendono necessarie, accade talvolta che i limiti si fondano.
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.
== Artefatti 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:
;Entity: Un oggetto che non è definito dai suoi attributi, ma piuttosto dalla sua identità. Ad esempio in una biblioteca dove ci interessa identificare ciascuna copia a disposizione degli utenti, i libro è una entity: nonostante il suo stato (disponibile, in prestito, smarrito, etc.) o la sua collocazione su scaffale possano cambiare, quel libro rimane fisicamente lo stesso oggetto.
;Value object: Un oggetto che ha una serie di attributi ma non ha identità concettuale. I value object devono essere trattati come oggetti immutabili. Per esempio quando le persone si scambiano [[Banconote in euro|banconote da cinque euro]], essi sono solo interessati al valore nominale della banconota, non alla singola identità delle banconote scambiate. In questo contesto, le banconote da cinque euro sono un value object: se la persona A ha una banconota da cinque euro, e la persona B ha una banconota da cinque, e 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 un contesto diverso, come per 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, nota come ''aggregate root''. L'entità radice di aggregazione incapsula 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, nel contesto di un reparto vendite un ordine può essere composto da più prodotti, e ha un totale che deve sempre corrispondere alla somma dei prezzi dei prodotti inclusi nell'ordine. È utile esprimere l'ordine come aggregate, in modo da poter garantire la consistenza del totale consentendo l'accesso ai prodotti solo tramite l'ordine. L'ordine, aggregate root, ha il compito di ricevere le richieste di modifica dei prodotti provenienti dall'esterno dell'aggregate, e di modificare il totale di conseguenza.
;Domain event: Un evento di dominio è un oggetto che rappresenta un evento che ha causato una modifica dello stato di una o più entità. Ad esempio, in una biblioteca, un prestito può essere un evento di dominio, in quanto rappresenta il cambio di stato 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.''
;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> .
;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.
=== 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 basato 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.
==
<references />
== Voci correlate ==
* [[Semantica]]
* [[Rappresentazione della conoscenza]]
* [[Ontologia]]
* [[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/interviews/jimmy-nilsson-___domain-driven-design |nome= James '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.infoq.com/articles/haywood-ddd-no |nome= Dan |cognome= Haywood |tipo= interview |editore= InfoQ |titolo= Domain Driven Design using Naked Objects}}
* {{
[[Categoria:Architettura del software]]
[[Categoria:Metodi di sviluppo software]]
| |||