introduzione al domain driven design (ddd)
DESCRIPTION
In questa sessione si approfondirà il concetto di Domain Driven Design, un principio di progettazione che può essere visto come una “forma-mentis” per aiutare a concepire e modellare applicazioni enterprise che fanno un forte uso del Domain Model. Questa metodologia, introdotta da Eric Evans, mette in risalto il dominio applicativo di un progetto, costituendo quindi il collante tra il modello analitico e il modello implementativo e trovando la sua naturale applicazione in ambienti di sviluppo agili come Extreme Programming. Come completamento della sessione verranno esaminate alcune tecniche di Layering e pattern architetturali che ben si sposano con questa tecnica.TRANSCRIPT
![Page 1: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/1.jpg)
Domain Driven Design: OverviewSpeaker: Giancarlo Sudano
![Page 2: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/2.jpg)
Giancarlo Sudano (alias janky)
Software Architect in Objectway
Fondatore di GUISA www.guisa.org
Blog su Ugidotnet: http://blogs.ugidotnet.org/janky
Email: [email protected]@objectway.it
About me:
![Page 3: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/3.jpg)
Agenda
• Domain Model• Domain Driven Design• Conceptual Map• Layering• Esempi reali: Web Client Software Factory
![Page 4: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/4.jpg)
DOMAIN MODEL
![Page 5: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/5.jpg)
Un po di discipline...
![Page 6: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/6.jpg)
Business Requirement
Processo di vendita
(testo)
Processo d’Ordine
(testo)
Use Case Model
Business Requirement
![Page 7: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/7.jpg)
Business Modeling
Processo di vendita
(testo)
Processo d’Ordine
(testo)
Use Case Model
Business Modeling
OrderCustome
r
Product
1
1..*
1..*
Domain Model
Business Requirement
Gli Use case, i termini, i concetti ispirano il
Domain Model
![Page 8: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/8.jpg)
Software Design
Business Modeling Software Design
OrderCustome
r
Product
1
1..*
1..*
I concetti del Dominio ispirano nomi e
comportamenti delle classi del software
Object ModelDomain Model
![Page 9: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/9.jpg)
Design del Domain LayerClassificazione 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à.
![Page 10: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/10.jpg)
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
![Page 11: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/11.jpg)
DOMAIN DRIVEN DESIGN
![Page 12: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/12.jpg)
...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…”
![Page 13: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/13.jpg)
Domain Driven Design: Il portale
• http://domaindrivendesign.org– Informazioni – Interviste– Articoli– Discussioni– Case Stories– Esempi
![Page 14: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/14.jpg)
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à.
![Page 15: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/15.jpg)
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.
![Page 16: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/16.jpg)
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.
![Page 17: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/17.jpg)
Esempio classico di discostamento
![Page 18: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/18.jpg)
La prima Conceptual Map di DDD
![Page 19: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/19.jpg)
Entity e ValueObject
![Page 20: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/20.jpg)
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
![Page 21: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/21.jpg)
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à
![Page 22: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/22.jpg)
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
![Page 23: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/23.jpg)
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
Business Rules
![Page 24: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/24.jpg)
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
Tipi di Services
![Page 25: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/25.jpg)
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
![Page 26: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/26.jpg)
Service dipendenti da classi (non da id)
![Page 27: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/27.jpg)
Responsabilità di creare e assemblare oggetti particolarmente complessi.
La logica di creazione di grafi immersa nel costruttore stesso, potrebbe non essere una “buona idea”.
Factory
![Page 28: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/28.jpg)
Responsabilità del ciclo di vita delle Entity.
Responsabilità infrastrutturali di persistenza quali Identity Map, Cache.
Repository
![Page 29: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/29.jpg)
LAYERING
![Page 30: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/30.jpg)
• Isolare il codice dalla interfaccia utente• Isolare il codice di accesso al database
Contesto classico
![Page 31: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/31.jpg)
Presentation
Business Logic
Data Access
Soluzione classica
![Page 32: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/32.jpg)
WinForm
Business Logic
Data Access(database A)
Compact Framework
Data Access(database B)
Web Form WPF Form
Soluzione classica
![Page 33: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/33.jpg)
Non se ne può più...andiamo oltre
![Page 34: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/34.jpg)
• Dominio– 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
Requisiti più alti
![Page 35: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/35.jpg)
Isolamento: LayeringUser Interface (Presentation Layer)Responsible for presenting information to the user andinterpreting user commands.
Application LayerThis is a thin layer which coordinates the applicationactivity. It does not contain business logic. It does nothold the state of the business objects, but it can holdthe state of an application task progress.
Domain Layer This layer contains information about the domain. Thisis the heart of the business software. The state ofbusiness objects is held here. Persistence of thebusiness objects and possibly their state is delegated tothe infrastructure layer.
Infrastructure LayerThis layer acts as a supporting library for all the otherlayers. It provides communication between layers,implements persistence for business objects, containssupporting libraries for the user interface layer, etc.
![Page 36: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/36.jpg)
Soluzione
Presentation
Business Logic
Data Access
UI Process
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
![Page 37: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/37.jpg)
Confusioni sui nomi di layer?
Presentation
Business
Data Access
UI Process
Presentation
Domain
Data Access
Controller/Mediator
Presentation
Domain
Data Source
Application Controller
Presentation
Domain
Infrastructure
Application
=
=
=
=
Brown Martin Fowler Eric Evans
Presentation
Business
Data Access
...
DNA, J2EE
![Page 38: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/38.jpg)
Soluzione
UI Process
Data Access
Business Rules
Entity (detto anche Core)
Presentation
Security Service Altri Service
Business Process
Validations
![Page 39: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/39.jpg)
Soluzione
UI Process
Data Access
Business Rules
Entity (detto anche Core)
Presentation
Security Service Altri Service
Business Process
Validations
![Page 40: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/40.jpg)
Service GatewayLayered Applications
![Page 41: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/41.jpg)
Presentation Layer
UserInterface Process Layer
CAB , CWAB, Acropolis , MonoRail, Workflow Foundation
Service Layer
ORM NHibernate, Linq to SQL, Genome
DatabaseLegacy WebServices EnterpriseServicesLDAP
Dependency Injection Framework(Spring.NET, Windsor)
AO
P F
ram
ewo
rkS
prin
g.ne
t, P
olic
y In
ject
ion
App
licat
ion
Blo
ck
Business Process Layer
Workflow Foundation, BizTalk, Spring Validation, Validation Application Block
DataAccess Layer
Authorization
CrossCutting Utility ClassException Handling, Logging, Security
Domain Layer
Authentication
Log e Trace
Transaction Management
![Page 42: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/42.jpg)
ALTRE NAVIGATION MAPS
![Page 43: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/43.jpg)
Supple Design Patterns
Eric Evans: Domain Driven Design [2006]
![Page 44: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/44.jpg)
Model Integrity Patterns
Eric Evans: Domain Driven Design [2006]
![Page 45: Introduzione al Domain Driven Design (DDD)](https://reader033.vdocuments.us/reader033/viewer/2022061201/546ac079af7959664c8b4f73/html5/thumbnails/45.jpg)
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”