Domain-driven design: differenze tra le versioni

Versione delle 18:07, 18 ott 2024

Versione attuale delle 10:33, 14 gen 2025

(2 versioni intermedie di 2 utenti non mostrate)

Riga 6:

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

* basare la progettazione di sistemi complessi sui modelli 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=2024-10-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|accessoanno=2024-10-182004|url=https://archive.org/details/domaindrivendesi0000evan|data=2004|editore=Addison-Wesley|ISBN=978-0-321-12521-7}}</ref>

== Definizioni fondamentali ==

Riga 21:

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-03-07|lingua=en|accesso=18 ottobre 2024-10-18}}</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=2024-10-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=2024-10-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.

Riga 46:

;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 ===

Riga 67:

* {{Cita pubblicazione|url= http://www.infoq.com/presentations/strategic-design-evans |nome= Eric |cognome= Evans | 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' |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/ |dataarchivio= 15 giugno 2009 }}

* {{Cita pubblicazione |url= http://www.methodsandtools.com/archive/archive.isp?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 |dataarchivio= 21 novembre 2010 |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= Novembernovembre 2010 |tipo= World Wide Web log |accesso= 19 maggio 2015 |dataarchivio= 12 agosto 2011 |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}}