Domain-driven design
Domain-driven design (DDD) è un approccio dello sviluppo del software che risolve problemi complessi connettendo l'implementazione ad un modello in evoluzione.[1] Le premesse del ___domain-driven sono le seguenti:
- 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.
Il termine è stato introdotto da Eric Evans nel libro dallo stesso titolo.[2]
Asserzioni fondamentali
- Dominio: Un contesto di conoscenza (ontologia), influenza, o attività. L'area in cui l'utente lavora con il software è il dominio dello stesso.
- Modello: Un sistema di astrazione che descrive specifici aspetti del dominio e che può essere usato per risolvere problematiche relative alla definizione del dominio.
- 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.
Strategie nel ___domain-driven design
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.
Il contesto delimitato e definito
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.
Quindi: La 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 qui 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.
See also
References
- ^ Domain driven design..
- ^ Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley, 2004, ISBN 978-032-112521-7. URL consultato il August 12, 2012..
External links
- Eric Evans, Domain Driven Design – Putting the Model to Work, InfoQ..
- Eric Evans, Domain Driven Design – Strategic Design, InfoQ..
- James ‘Jimmy’ Nilsson, Domain Driven Design, InfoQ..
- Domain-Driven Design, Yahoo!..
- An Introduction to Domain Driven Design, Methods & tools..
- Gregory ‘Greg’ Young, CQRS, Task Based UIs, Event Sourcing agh!, Code better, 16 febbraio 2010..
- Jon Jenkins, Domain‐driven design that works, Clever Labs, November 2010.: Domain Driven Design's importance in the business.
- Udi Dahan, Clarified CQRS, 9 dicembre 2009.: how it relates to other patterns]
- Dan Haywood, Domain Driven Design using Naked Objects, InfoQ..
- Daniel Whittaker, How to Build an Aggregate Root for CQRS and Event Sourcing..