Domain-driven design: differenze tra le versioni

Versione delle 20:56, 17 set 2024

Versione delle 15:06, 18 ott 2024

Riga 1:

'''Domain-driven design''' ('''DDD''') è un approccio delloalla sviluppoprogettazione del software che risolvepunta problemia complessiriprodurre connettendoa l'implementazionelivello addel software un modellodominio inapplicativo, evoluzionebasandosi sull'input degli esperti di quel dominio. LeIl premesseDDD delpunta ___domain-drivena sonosuddividere lei seguenti:sistemi in contesti circoscritti, ciascuno con il proprio modello, piuttosto che a progettare un singolo modello onnicomprensivo.

* Puntare 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>{{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 sui seguenti obbiettivi:

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

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

* Iniziaremantenere una creativa collaborazione tra tecnici ed esperti di dominio per definirerifinire in maniera iterativa unmodelli modello concettualeconcettuali che possapossano essere applicatoapplicati ai particolari problemi del casodominio.

Il termine "Domain-driven design" è stato introdottoconiato da [[Eric Evans (technologist)|Eric Evans]] nel libro2003 dallonel stessolibro titoloomonimo.<ref>{{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>

== Definizioni fondamentali ==

Line 50 ⟶ 54:

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.

=== Note ===

<references />

=== Voci correlate ===

* [[Semantica]]

* [[Rappresentazione della conoscenza]]

Line 59 ⟶ 63:

* [[Rete semantica]]

=== Collegamenti esterni ===

* {{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 | editore= InfoQ |tipo= presentation |titolo= Domain Driven Design – Strategic Design}}