idiomatic domain driven design
DESCRIPTION
TRANSCRIPT
![Page 1: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/1.jpg)
Idiomatic Domain Driven Design
Andrea Saltarello [email protected] http://blogs.ugidotnet.org/pape http://twitter.com/andysal74
http://creativecommons.org/licenses/by-nc-nd/2.5/
![Page 2: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/2.jpg)
DDD
Domain Driven Design:
• è un approccio alla realizzazione del software pensato per contenere la complessità
• Non è un silver bullet
![Page 3: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/3.jpg)
Ubiquitous Language
E’ il linguaggio utilizzato nelle discussioni tra tutti i partecipanti al progetto, nei diagrammi, nella documentazione e nel codice, diventando così comune a tutti gli attori che partecipano alla realizzazione del software
Attenzione ai dialetti!
![Page 4: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/4.jpg)
Ubiquitous Language: falsi positivi
Nella sua definizione di segno linguistico, Ferdinand de Saussure distingue: • un elemento formale, o esterno,
costituito dal significante, • e un elemento intrinseco, concettuale,
costituito dal significato. Qualsiasi segno esiste solo grazie alla relazione tra significante e significato. In altre parole, il significante è la forma, fonica o grafica, utilizzata per richiamare l'immagine che, nella nostra mente, è associata a un determinato concetto, o significato.
![Page 5: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/5.jpg)
Bounded Context
Un Bounded Context è un contesto all’interno del quale è valido uno specifico ubiquitous language
Un sistema può quindi essere una composizione di contesti differenti (es: web store, accountability, delivery&shipment …), comunicanti tra di loro mediante una Context Map
Ogni bounded context è (quasi) un sistema a sè
![Page 6: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/6.jpg)
Architettura di DDD
![Page 7: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/7.jpg)
Architettura di DDD
è una layered architecture
i layer Presentation e Infrastructure compaiono «per sport» nel diagramma
i layer Application e Domain costituiscono quella che tipicamente chiamiamo «business logic»
Domain: logica invariante per i casi d’uso
Application: logica specifica ai casi d’uso
![Page 8: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/8.jpg)
IL DOMAIN LAYER
![Page 9: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/9.jpg)
Domain Layer: Key Concepts
Il Domain Layer contiene la domain logic ed è composto da
Model: Entità (identità e stato) e Valori (solo stato) Servizi
Entità e Valori a runtime formano dei grafi di oggetti. I grafi dotati di “dignità propria” sono chiamati Aggregate e il sistema (es: i Repository) si “impegna” a gestirli correttamente ed atomicamente Le istanze di entità/aggregate sono costruite da Factory
![Page 10: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/10.jpg)
Domain Model: precisazioni
Non stiamo modellando la realtà assoluta, bensì un modello funzionale all’interno di un bounded context
![Page 11: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/11.jpg)
Da 0 ad Aggregate
E' un insieme di elementi raggruppati in un’unità logica, quindi un grafo di oggetti
Ha come radice l'entità principale dell'aggregato
La radice è l’unico elemento che può essere referenziato fuori dai confini dell’aggregato
Non è possibile agire direttamente sugli elementi senza passare dalla radice dell'aggregato
L’aggregate ha la responsabilità di implementare la propria logica
![Page 12: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/12.jpg)
Domain Model
![Page 13: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/13.jpg)
Repository pattern
Mediates between the domain and data mapping layers
using a collection-like interface for accessing domain
objects.
Ricapitolando:
• Interfaccia “collection like” • Gestisce la persistenza degli Aggregate • LINQ! (siamo dei buongustai )
![Page 14: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/14.jpg)
IRepository<T>
![Page 15: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/15.jpg)
Repository++
Quisquilie IT:
Code Contracts
Repository <3 IoC
![Page 16: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/16.jpg)
APPLICATION LAYER
![Page 17: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/17.jpg)
Application Layer: in teoria
Application Layer: defines the jobs the software is supposed to do and directs the expressive domain objects to work out problems. The tasks this layer is responsible for are meaningful to the business or necessary for interaction with the application layers of other systems. This layer is kept thin. It does not contain business rules or knowledge, but only coordinates tasks and delegates work to collaborations of domain objects in the next layer down. It does not have state reflecting the business situation, but it can have state that reflects the progress of a task for the user or the program.
![Page 18: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/18.jpg)
Application Layer: in pratica
E’ un catalogo di servizi in grado di effettuare il mesh della logica presente nel domain layer esponendola alla applicazione (es: presentation layer) in una forma ad… alta digeribilità
![Page 19: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/19.jpg)
PRESENTATION LAYER
![Page 20: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/20.jpg)
Presentation Layer vs. DDD
Avere a disposizione un domain layer «smart» è bello, ma costoso:
Materializzazione degli oggetti
Mesh della business logic
Tipicamente, si finisce per passare la vita a «fare DTO»:
Domain Layer <-> Application Layer
Application Layer <-> Presentation Layer
![Page 21: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/21.jpg)
MVC - Model View Controller
View Controller
Model
User action
Set state Update state
Change view
View e Controller conoscono Model
Solo Controller agisce verso Model
View è passiva
Model è indipendente da View e Controller
![Page 22: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/22.jpg)
MVC: Falsi miti
Lo scopo del Controller non è di separare la View dal Model. La responsabilità del Controller è di fare da mediatore tra l'utente e l'applicazione, non tra la View e il Model. Nella “web suburbia” si dice MVC, ma si intende Model 2 [JSP specs]
![Page 23: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/23.jpg)
Model 2
In a Model 2 application, requests from the client browser are passed to the controller, which is a servlet. The controller decides which view (JSP) it will pass the request to. The view then invokes methods in a JavaBean (which may access a database) and returns the Response object to the Web container, which is then passed on to the client browser. [Wikipedia] Legenda:
• Servlet->HttpHandler->Front Controller [P of EAA, 344]
• JSP->Controller->Page Controller [P of EAA, 333]
![Page 24: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/24.jpg)
MVC @ Managed Designs
In bottega usiamo ASP.NET MVC dalle prime CTP della v1, ed abbiamo raggiunto una struttura «standardizzata» dei progetti:
Model 3
Layered Expression Trees
![Page 25: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/25.jpg)
MVC goes Model 3
Model 2 separa il Controller in:
Front Controller
Page Controller
Model 3 separa il Model in:
View Model: rappresenta i dati che la view si impegna a presentare all’utente
Worker Service: è la façade verso il Domain Layer che il page controller utilizza per produrre il View Model (Application Layer in DDD)
![Page 26: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/26.jpg)
Never mind the bollocks, here’s the Model 3
![Page 27: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/27.jpg)
Layered Expression Trees (LET idiom)
Facciamo un gioco: invece di definire un «botto» di DTO, facciamo che layer e servizi si scambino degli IQueryable<YourFavouriteDomainEntity>, facendo «emergere» la query e specificando la proiezione solo all’ultimo momento?
L’espressione «Capra e cavoli» vi dice niente?
![Page 28: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/28.jpg)
C’mon Query LET’s go party (ah-ah-ah, yeah!)
![Page 29: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/29.jpg)
MVVM Presentation Model
Represent the state and behavior of the presentation independently of the GUI controls used in the interface The Presentation Model coordinates with the domain layer and provides an interface to the view that minimizes decision making in the view.
![Page 30: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/30.jpg)
MVVM vs. DDD
• WPF: il ViewModel può consumare il domain layer senza limitazioni
• Silverlight: il ViewModel non ha accesso al model
![Page 31: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/31.jpg)
MVVM vs. Bottega51
• WPF: il ViewModel può consumare il domain layer senza limitazioni
• Silverlight: il ViewModel non ha accesso al model
![Page 32: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/32.jpg)
Conclusioni
DDD permette di «concepire» ed «organizzare» un sistema in modo efficace
IQueryable<T> supporta DDD abbassando il costo della materializzazione degli oggetti
ASP.NET MVC rocks!
![Page 33: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/33.jpg)
SOFTWARE ENGINEERING Appendix 1
![Page 34: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/34.jpg)
Cosa è l’Architettura?
Secondo la definizione ISO/IEC 42010:
“L’organizzazione basilare di un sistema,
rappresentato dalle sue componenti, dalle relazioni che esistono tra di loro e con l’ambiente circostante, e dai principi che governano la sua progettazione e evoluzione."
![Page 35: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/35.jpg)
ISO/IEC 42010 fact sheet
Titolo: IEEE Recommended Practice for Architectural Description of Software-Intensive Systems
Scope: This recommended practice addresses the architectural
description of software-intensive systems. A software-intensive system is any system where software contributes essential influences to the design, construction, deployment, and evolution of the system as a whole.
architect: The person, team, or organization responsible for
systems architecture. architecting: The activities of defining, documenting,
maintaining, improving, and certifying properimplementation of an architecture.
architecture: The fundamental organization of a system
embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.
![Page 36: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/36.jpg)
Architettura: cosa?
L’architettura di un sistema *è* definita durante la fase di progettazione.
L’architettura *non è* parte dell’analisi:
l’analisi si concentra su cosa debba fare il sistema
La progettazione si concentra su come debba farlo
![Page 37: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/37.jpg)
Architetto: le responsabilità
L’architetto:
Recepisce i requisiti funzionali (emersi durante l’analisi) e quelli non funzionali (es: HA, scalabilità, security …)
Suddivide i grandi sistemi in (layer di) sottosistemi individualmente assegnabili ad uno sviluppatore o ad un gruppo di lavoro
Effettua una analisi del rapporto costi/benefici per determinare il miglior modo di soddisfare i requisiti, eventualmente ricorrendo a componenti commerciali o comunque già sviluppati
Genera “specifiche”: sketch, modelli o prototipi per comunicare al gruppo di lavoro le modalità di realizzazione
![Page 38: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/38.jpg)
Architettura: luoghi comuni
Architetto != Analista
Architetto != Project Manager
Architettura != Design
Al limite… Design Architettura
![Page 39: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/39.jpg)
Architettura: rappresentazione
L’architettura si rappresenta mediante le view, che sono la rappresentazione del sistema osservato da un certo view point.
Tutto fa brodo, ma ISO 19501 (UML) offre alcuni view point “significativi” espressi con una notazione *standard*
![Page 40: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/40.jpg)
Requisito: una definizione
1. Condizione o capacità che occorre all’utente per risolvere un problema o raggiungere un obiettivo
2. Condizione o capacità che deve essere raggiunta o posseduta dal sistema per soddisfare un contratto, standard, specifica o altro documento formale
3. La rappresentazione documentata di una condizione o capacità (1 o 2)
![Page 41: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/41.jpg)
Requisiti: la teoria
La norma ISO9126, pubblicata nella sua prima versione nel 1991, ha definito il modello dei requisiti qualitativi del software.
Secondo tale modello i requisiti sono raggruppabili in 6 "caratteristiche" e in 21 "sottocaratteristiche“, distinte fra caratteristiche esterne (orientate all’utente) e caratteristiche interne (orientate allo sviluppo e manutenzione).
![Page 42: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/42.jpg)
Funzionalità
Capacità di soddisfare esigenze esplicite od implicite.
Idoneità = funzionalità appropriate per specificati compiti
Accuratezza = precisione dei risultati
Interoperabilità = capacità di interagire con altre applicazioni
Sicurezza = protezione da utilizzi non autorizzati
Concordanza = aderenza a standard o regolamentazioni legislative
![Page 43: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/43.jpg)
Disponibilità
Capacità di fornire una continuità di servizio
Maturità = mancanza di interruzioni per malfunzionamenti
Tolleranza = ridotto degrado in caso di malfunzionamenti
Recupero = capacità e velocità di ripristino dopo interruzioni
![Page 44: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/44.jpg)
Usabilità
Facilità di utilizzo da parte degli utenti
Comprensione = acquisizione di adeguato livello di conoscenza
Apprendimento = velocità di familiarizzazione
Utilizzabilità = facilità di uso e controllo
Attrattiva = livello di gradimento nell’utilizzo
![Page 45: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/45.jpg)
Efficienza
Capacità di fornire prestazioni adeguate
Tempo Risposta = reattività agli stimoli dell’utente
Utilizzo risorse = utilizzo adeguato delle risorse del sistema
![Page 46: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/46.jpg)
Manutenibilità
Facilità di manutenzione correttiva e evolutiva
Analizzabilità = facilità di diagnosi e identificazione componenti
Modificabilità = facilità di inserimento di modifiche
Stabilità = limitazione di effetti indesiderati derivanti da modifiche
Collaudabilità = facilità di testare le modifiche apportate
![Page 47: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/47.jpg)
Portabilità
Trasferibilità da un ambiente all’altro
Adattabilità = facilità di adeguamento ad un nuovo ambiente
Installabilità = velocità e completezza di installazione
Coesistenza = capacità di risiedere con altre applicazioni nello stesso ambiente
Sostituibilità = capacità di rimpiazzare un’altra applicazione con simili funzionalità
![Page 48: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/48.jpg)
Recepire i requisiti
La mancanza di requisiti o la mancanza della loro gestione sono tra le cause principali del fallimento dei progetti
Recepire i requisiti significa circoscrivere il problema
Strumenti utilizzati in bottega:
• Use case
• User story
![Page 49: Idiomatic Domain Driven Design](https://reader034.vdocuments.net/reader034/viewer/2022051013/5484bf1ab47959d30c8b4cc2/html5/thumbnails/49.jpg)
FINE