Il documento fornisce una panoramica sul Domain Driven Design (DDD), evidenziando la sua importanza nella progettazione software per domini complessi, con particolare enfasi su modelli analitici e architetture stratificate. Giancarlo Sudano discute le definizioni chiave, analizza modelli e pattern pratici e offre risorse per approfondire il tema. Il DDD è descritto come un mindset per migliorare la connessione tra la progettazione concettuale e l'implementazione software.

1. Domain Driven Design: Overview
Speaker: Giancarlo Sudano

2. About me:
Giancarlo Sudano (alias janky)
Software Architect in Objectway
Fondatore di GUISA
www.guisa.org
Blog su Ugidotnet:
http://blogs.ugidotnet.org/janky
Email:
giancarlo.sudano@gmail.com
giancarlo.sudano@objectway.it

3. Agenda
• Domain Model
• Domain Driven Design
• Conceptual Map
• Layering
• Esempi reali: Web Client Software Factory

4. DOMAIN MODEL

5. Un po di discipline...

6. Business Requirement
Business Requirement
Use Case Model
Processo di
vendita
(testo)
Processo
d’Ordine
(testo)

7. Business Modeling
Use Case Model
Processo di
vendita
(testo)
Processo
d’Ordine
(testo)
Business Modeling
Domain Model
Order
Custome
r
Product
1
1..*
1..*
Business Requirement
Gli Use case, i termini, i
concetti ispirano il
Domain Model

8. Software Design
Business Modeling Software Design
Domain Model Object Model
Order
Custome
r
Product
1
1..*
1..*
I concetti del Dominio
ispirano nomi e
comportamenti delle classi
del software

9. Design del Domain Layer
Classificazione fatta da Fowler [PoEAA 2004]
Transaction Script:
Principalmente il layer sarà modellato con delle procedure che prendono
l’input dal layer di presentation, li processano e eventualmente trasmettono
manipolazioni sui database.
Table Module:
Serie di classi che gestiscono la logica di business
per tutte le righe sul database di una particolare entità.
Domain Model:
Serie di classi ispirate al modello analitico che gestiscono
sia stato che comportamento. Una singola istanza rappresenta una singola entità.

10. Riepilogo delle definizioni
• Modello analitico: concettualizzazione del problema di
business
• Domain Layer: Strato di software che rappresenta
l’implementazione del modello analitico
• Domain Layer patterns: metodologie per implementare i
problemi di business
– Transaction script
– Table Module
– Domain Model

11. DOMAIN DRIVEN DESIGN

12. ...tutto cominciò...
• Formalizzazione fatta da Eric Evans 2003/04 nel
suo libro
“Domain Driven Design:
Tackling Complexity In The Heart Of Software”
• Scopo del libro:
– “…To describe and build a vocabulary about the very art
of domain modeling…”

13. Domain Driven Design: Il portale
• http://domaindrivendesign.org
– Informazioni
– Interviste
– Articoli
– Discussioni
– Case Stories
– Esempi

14. Domain Driven Design: Definizione
 La DDD è un mindset, cioè una serie di principi e
priorità, atte ad accelerare la progettazione software
che ha a che fare con domini di particolare
complessità.

15. Presupposti per la nascita di DDD
• Il modello analitico (cioè il risultato del lavoro degli
analisti) è uno strumento di sola comprensione.
• Un analista poi può usare UML per la visualizzazione del
modello stesso.
• Il modello non porterà nessun dettaglio implementativo
ai fini di non inquinare la comprensione.

16. Quindi...
• l'implementazione di un modello molte volte può
allontanarsi notevolmente dalla sua iniziale descrizione.
• La Domain Driven Design è una disciplina di
progettazione atta quindi a tenere costantemente
vicini/connessi il modello analitico che il modello
implementativo.

17. Esempio classico di discostamento

18. La prima Conceptual Map di DDD

19. Entity e ValueObject

20. Entity Value Object
Semantica Semantica di Reference:
Una Fattura, un Ordine, un Cliente
Semantica di Valore:
Un Indirizzo, una Coordinata 3D, un
Numero Complesso
Life cycle Indipendente Coincidente con l’oggetto a cui
appartiene
Uso Una Entity tende a memorizzare uno
stato, esporre comportamenti e
coordinare altre entity/value object
associati
Un value object tende a memorizzare
uno stato
Uguaglianza Basata sull’identità.
Cioè dal confronto di uno (o più)
attributi specifici che la
rappresentano univocamente.
Basata sul confronto di tutti i suoi
attributi.
Rappresentazione nel
modello Object
Oriented
Una Classe Una Classe (o uno Struct)
Rappresentazione nel
modello relazionale
Una (o più) tabelle Una (o più) colonne di una tabella

21. Troppa logica nelle entity?
In generale si tende ad aggiungere solo i metodi
essenziali ad una entity.
Inserire troppa logica all’interno di una entity:
+ Complessità
- Manutenibilità
- Chiarezza, Espressività

22. Service
Una classe Service modella, non tanto una entità di dominio,
ma una regola di business
Qualcosa che il software “deve fare” (operazione) e che non
necessariamente coincide con uno stato

23. Business Rules
Restrictions:
Un cliente non può inserire più di tre richieste d’ordine caricate sul suo credit account.
Heuristics:
Gli ordini di un cliente con uno stato preferenziale verranno evasi immediatamente.
Computations:
Il volume di ordini annuale di un cliente deve essere calcolato dal totale delle vendite chiuse entro la
chiusura dell’anno fiscale aziendale.
Inference:
Un cliente deve essere considerato preferenziale se ha almeno 5 ordini superiori a 1000 euro.
Timing:
Un cliente verrà archiviato se non effettua ordini per 36 mesi consecutivi.
Triggers:
Quando un ordine è stato spedito, una notifica di “Send advance” deve essere notificata ad una serie di
sottoscritti

24. Tipi di Services
Tipologie di Servizi Esempi
Infrastrutturali •Spedizione di una Mail
•Persistenza di una entity in uno storage
•Tracciamento delle operazioni di una
Entity
Applicativi (o di
dominio)
•Trasferimento di valuta tra conti bancari
•Approvazione di un Ordine d’acquisto
•Validazione di Entity a fronte di una
operazione di business

25. Come distribuire logica tra
Service e Entity?
Una Entity con troppe responsabilità rischia di perdere in
chiarezza concettuale.
Entity troppo cariche sono di difficile manutenzione,
refactoring e testing.
Le operazioni di business, sono spesso legate ad altre
entity. Esprimere queste operazioni come metodo di una
Entity, aumenta la sua dipendenza da altri oggetti

26. Service dipendenti da classi
(non da id)

27. Factory
Responsabilità di creare e assemblare oggetti
particolarmente complessi.
La logica di creazione di grafi immersa nel costruttore
stesso, potrebbe non essere una “buona idea”.

28. Repository
Responsabilità del ciclo di vita delle Entity.
Responsabilità infrastrutturali di persistenza quali Identity
Map, Cache.

29. LAYERING

30. Contesto classico
• Isolare il codice dalla interfaccia utente
• Isolare il codice di accesso al database

31. Soluzione classica
Presentation
Business Logic
Data Access

32. WinForm
Soluzione classica
Compact
Framework
Web Form WPF Form
Business Logic
Data Access
(database A)
Data Access
(database B)

33. Non se ne può più...andiamo
oltre 

34. • Dominio
Requisiti più alti
– Domain Model quanto più indipendente da tutte le altre parti del sistema.
– E’ buona norma rendere il DM facilmente testabile, modificabile.
– Minimizzare la dipendenza anche dalle API di .NET.
• Presentation Layer
– Riutilizzo più pesante del codice tra una Presentation Layer ed un altro
– Migliorare le capacità di Test delle View e della logica di Flusso
• Servizi:
– Distinzione tra servizi infrastrutturali e applicativi

35. Isolamento: Layering
User Interface (Presentation Layer)
Responsible for presenting information to the user and
interpreting user commands.
Application Layer
This is a thin layer which coordinates the application
activity. It does not contain business logic. It does not
hold the state of the business objects, but it can hold
the state of an application task progress.
Domain Layer
This layer contains information about the domain. This
is the heart of the business software. The state of
business objects is held here. Persistence of the
business objects and possibly their state is delegated to
the infrastructure layer.
Infrastructure Layer
This layer acts as a supporting library for all the other
layers. It provides communication between layers,
implements persistence for business objects, contains
supporting libraries for the user interface layer, etc.

36. Soluzione
Presentation
UI Process
Business Logic
Data Access
Coordina le attività
dell’applicazione.
Non contiene logica di
business.
Non gestisce lo stato delle
Entity, ma gestisce lo stato
dell’applicazione e dei
progresso dei task
Può eseguire Processi di
Business e Servizi in
seguito a comandi dalla UI
o a Eventi Esterni

37. Confusioni sui nomi di layer?
Presentation
UI Process
Business
Data Access
Presentation
Controller/
Mediator
Domain
Data Access
Presentation
Application
Controller
Domain
Data Source
Presentation
Application
Domain
Infrastructure
=
=
=
=
Brown Martin Fowler Eric Evans
DNA, J2EE
Presentation
...
Business
Data Access

38. Soluzione
Presentation
UI Process
Data Access
Business Rules
Entity (detto anche Core)
Security Service Altri Service
Business Process
Validations

39. Soluzione
Presentation
UI Process
Data Access
Business Rules
Entity (detto anche Core)
Security Service Altri Service
Business Process
Validations

40. Service Gateway
Layered Applications

41. Presentation Layer
UserInterface Process Layer
CAB , CWAB, Acropolis ,
MonoRail, Workflow Foundation
Service Layer
ORM
NHibernate, Linq to SQL, Genome
Dependency Injection Framework
(Spring.NET, Windsor)
Legacy WebServices LDAP EnterpriseServices Database
AOP Framework
Spring.net, Policy Injection Application Block
Business Process Layer
Workflow Foundation, BizTalk,
Spring Validation, Validation Application Block
DataAccess Layer
CrossCutting Utility Class
Exception Handling, Logging, Security
Authorization
Domain Layer
Authentication
Log e Trace
Transaction
Management

42. ALTRE NAVIGATION MAPS

43. Supple Design Patterns
Eric Evans: Domain Driven Design [2006]

44. Model Integrity Patterns
Eric Evans: Domain Driven Design [2006]

45. Riferimenti
• Libro: Domain Driven Design: Tackling Complexity In The
Heart Of Software
[Eric Evans 2003]
• Libro: Applying Domain-Driven Design and Patterns
[Jimmy Nilsson 2006]
• Libro: Domain Driven Design Quickly
[InfoQ 2006] (gratuito, scaricabile da internet)
• http://domaindrivendesign.org/
• Seguite il mio blog:
iniziativa: “Domain Model e Enterprise Application”