Appunti su Domain Driven Design

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

Print

Comments on this entry:

# re: Appunti su Domain Driven Design

Left by Paolo at 05/06/2007 12:37
Gravatar
grande! per un neofita sono quelle 2 - 3 definizioni che servono a fare un pò di chiarezza
Comments have been closed on this topic.
«giugno»
domlunmarmergiovensab
2627282930311
2345678
9101112131415
16171819202122
23242526272829
30123456