Domain-driven design: differenze tra le versioni

Versione delle 13:12, 6 lug 2015

Versione delle 22:06, 27 ott 2015

Riga 36:

== Costruire le basi del DDD ==

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-0320-112521321-12521-7|accessdateaccesso=August 12, agosto 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à. Per esempio, la maggior parte delle compagnie aeree distinguono in modo univoco ogni sedile su ogni volo. Ogni sedile è un'entità in questo contesto. Tuttavia, Southwest Airlines, EasyJet e Ryanair non distinguono tra tutti i sedili; Tutti i sedili sono uguali. In questo contesto, il sedile è in realtà un value object.

;Value Object: Un oggetto che ha una serie di attributi ma non ha identità concettuale. Devono essere trattati come immutabile. Per esempio quando le persone si scambiano banconote da un dollaro, che in genere non distinguono tra un unico prototipo; sono solo preoccupati per il valore nominale della banconota. In questo contesto, le banconote da un dollaro sono value object. Tuttavia, la Federal Reserve potrebbe essere preoccupata per ogni pagamento unico; In questo contesto, ogni prototipo potrebbe essere un'entità.''