2. DDD
Domain Driven Design:
• è un approccio alla realizzazione del
software pensato per contenere la
complessità
• Non è un silver bullet
3. 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!
4. 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.
5. 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è
7. 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
9. 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
10. Domain Model: precisazioni
Non stiamo
modellando la
realtà assoluta,
bensì un modello
funzionale
all’interno di un
bounded context
11. 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
13. 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 )
17. 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.
18. 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à
20. 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
21. MVC - Model View Controller
Update state Set state
Model
View Change view Controller
User action
View e Controller conoscono Model
Solo Controller agisce verso Model
View è passiva
Model è indipendente da View e Controller
22. 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]
23. 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]
24. 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
25. 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)
27. 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?
29. 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.
30. MVVM vs. DDD
• WPF: il ViewModel può consumare il
domain layer senza limitazioni
• Silverlight: il ViewModel non ha
accesso al model
31. MVVM vs. Bottega51
• WPF: il ViewModel può consumare il
domain layer senza limitazioni
• Silverlight: il ViewModel non ha
accesso al model
32. 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!
34. 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."
35. 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.
36. 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
37. 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
38. Architettura: luoghi comuni
Architetto != Analista
Architetto != Project Manager
Architettura != Design
Al limite… Design Architettura
39. 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*
40. 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)
41. 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).
42. 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
43. 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
44. 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
45. Efficienza
Capacità di fornire prestazioni adeguate
Tempo Risposta = reattività agli stimoli
dell’utente
Utilizzo risorse = utilizzo adeguato delle
risorse del sistema
46. 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
47. 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à
48. 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
