Appunti liberamente presi dal web cast Domain Driven Design di Giancalo Sudano
Formalizzazione
La formalizzazione viene fatta da Eric Evans nel suo libro “Tackling Complexity in the Heart of Software”.
Informazioni si possono avere su http://domaindrivendesign.org/.
Definizioni di partenza
Il Modello Analitico rappresenta il problema visto dal punto di vista di chi conosce il domino.
Viene descritto dall’analista insieme al committente e può essere formalizzato ad esempio uml.
Domain Layer è lo strato di software che rappresenta l’implementazione del modello analitico.
Il domain layer può essere implementato tramite alcune pattern:
- Transaction Script, è la visione più procedurale
- Table Model, il dato è centrale, il domino è legato al database
- Domain Model, il domino è modellato tramite classi
Domain Driven Design
La domain driven design è una tecnica che permette di tenere connessi il modello analitico e il modello implementativo.
Durante un progetto, infatti, capita che la parte implementativa si distacchi da quello che era il modello analitico.
Domain Model qualche principio
Il domain model è un “object model” in cui ogni singola classe ha uno specifico significato di business, e può incorporare sia “dati” che “comportamento”.
Il domain model non lavora direttamente con la rappresentazione tabulare dei dati ma tramite un modello ad oggetti.
Il concetto di Entity differisce dal concetto di Value Object.
Le classi di un domain model possono avere “associazioni” fino a formare una vera e propria rete di interconnessioni
Diventa importante quando possibile identificare le relazioni tramite reference.
Le classi del domain model possono modellare sia le “Entità” che le “Regole di Business”
I Servizi rappresentano le azioni che coinvolgono le azioni.
Quando una entità incorpora troppa logica diventa difficilmente mantenibile.
Quando una entità incorpora logica crea delle dipendenze.
La logica di Business del domain model interagisce a sua volta con “istanze di classi”
Nei servizi è importante ricordarsi che si sta lavorando con un domain model e i parametri in ingresso probabilmente saranno istanze di entità.
Isolamento
L’isolamento è importante perché:
- Indipendenza tra classi
- Testabilità e modificabilità
- Trasversalità del domain model
- Minima dipendenza da api di .NET
Layering Isolation
Una versione modificata del layering isolation che mette in primo piano le entity rendendole più isolate possibile.
Factory e Repositories
Le factory ci permette di separare la responsabilità per la creazione e assemblaggio per oggetti complessi.
Repositories gestiscono il ciclo di vita della entità Identity Map Cache
posted @ martedì 5 giugno 2007 02:22