Idiomatic Domain Driven Design

Idiomatic Domain Driven Design

Andrea Saltarello andreas@manageddesigns.it http://blogs.ugidotnet.org/pape http://twitter.com/andysal74

http://creativecommons.org/licenses/by-nc-nd/2.5/

DDD

Domain Driven Design:

• è un approccio alla realizzazione del software pensato per contenere la complessità

• Non è un silver bullet

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!

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.

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è

Architettura di DDD

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

IL DOMAIN LAYER

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

Domain Model: precisazioni

Non stiamo modellando la realtà assoluta, bensì un modello funzionale all’interno di un bounded context

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

Domain Model

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 )

IRepository<T>

Repository++

Quisquilie IT:

Code Contracts

Repository <3 IoC

APPLICATION LAYER

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.

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à

PRESENTATION LAYER

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

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

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]

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]

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

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)

Never mind the bollocks, here’s the Model 3

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?

C’mon Query LET’s go party (ah-ah-ah, yeah!)

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.

MVVM vs. DDD

• WPF: il ViewModel può consumare il domain layer senza limitazioni

• Silverlight: il ViewModel non ha accesso al model

MVVM vs. Bottega51

• WPF: il ViewModel può consumare il domain layer senza limitazioni

• Silverlight: il ViewModel non ha accesso al model

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!

SOFTWARE ENGINEERING Appendix 1

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."

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.

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

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

Architettura: luoghi comuni

Architetto != Analista

Architetto != Project Manager

Architettura != Design

Al limite… Design Architettura

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*

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)

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).

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

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

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

Efficienza

Capacità di fornire prestazioni adeguate

Tempo Risposta = reattività agli stimoli dell’utente

Utilizzo risorse = utilizzo adeguato delle risorse del sistema

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

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à

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

FINE