Your SlideShare is downloading. ×
0
Idiomatic Domain Driven DesignAndrea Saltarelloandreas@manageddesigns.ithttp://blogs.ugidotnet.org/papehttp://twitter.com/...
DDDDomain Driven Design:• è un approccio alla realizzazione del  software pensato per contenere la  complessità• Non è un ...
Ubiquitous LanguageE’ il linguaggio utilizzato nellediscussioni tra tutti i partecipanti alprogetto, nei diagrammi, nellad...
Ubiquitous Language: falsi positiviNella sua definizione di segno linguistico,Ferdinand de Saussure distingue:• un element...
Bounded ContextUn Bounded Context è un contestoall’interno del quale è valido unospecifico ubiquitous languageUn sistema p...
Architettura di DDD
Architettura di DDD è una layered architecture i layer Presentation e Infrastructure compaiono «per sport» nel diagramma i...
IL DOMAIN LAYER
Domain Layer: Key Concepts  Il Domain Layer contiene la domain  logic ed è composto da    Model: Entità (identità e stato)...
Domain Model: precisazioni                    Non stiamo                    modellando la                    realtà assolu...
Da 0 ad Aggregate  E un insieme di elementi raggruppati in  un’unità logica, quindi un grafo di oggetti  Ha come radice le...
Domain Model
Repository pattern Mediates between the domain and data mapping layers using a collection-like interface for accessing dom...
IRepository<T>
Repository++Quisquilie IT:  Code Contracts  Repository <3 IoC
APPLICATION LAYER
Application Layer: in teoriaApplication Layer: defines the jobs thesoftware is supposed to do and directs theexpressive do...
Application Layer: in praticaE’ un catalogo di servizi in grado dieffettuare il mesh della logica presentenel domain layer...
PRESENTATION LAYER
Presentation Layer vs. DDDAvere a disposizione un domain layer«smart» è bello, ma costoso:     Materializzazione degli ogg...
MVC - Model View Controller   Update state                               Set state                            Model       ...
MVC: Falsi miti  Lo scopo del Controller non è di  separare la View dal Model.  La responsabilità del Controller è di  far...
Model 2    In a Model 2 application, requests from the    client browser are passed to the controller,    which is a servl...
MVC @ Managed DesignsIn bottega usiamo ASP.NET MVC dalleprime CTP della v1, ed abbiamoraggiunto una struttura«standardizza...
MVC goes Model 3 Model 2 separa il Controller in:   Front Controller   Page Controller Model 3 separa il Model in:   View ...
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 s...
C’mon Query LET’s go party (ah-ah-ah, yeah!)
MVVM Presentation ModelRepresent the state and behavior of thepresentation independently of the GUIcontrols used in the in...
MVVM vs. DDD• WPF: il ViewModel può consumare il  domain layer senza limitazioni• Silverlight: il ViewModel non ha  access...
MVVM vs. Bottega51• WPF: il ViewModel può consumare il  domain layer senza limitazioni• Silverlight: il ViewModel non ha  ...
Conclusioni  DDD permette di «concepire» ed  «organizzare» un sistema in modo  efficace  IQueryable<T> supporta DDD  abbas...
Appendix 1SOFTWARE ENGINEERING
Cosa è l’Architettura?Secondo la definizione ISO/IEC 42010:  “L’organizzazione basilare di un sistema,     rappresentato d...
ISO/IEC 42010 fact sheetTitolo: IEEE Recommended Practice for Architectural    Description of Software-Intensive SystemsSc...
Architettura: cosa?L’architettura di un sistema *è*   definita durante la fase di   progettazione.L’architettura *non è* p...
Architetto: le responsabilitàL’architetto:   Recepisce i requisiti funzionali (emersi durante   l’analisi) e quelli non fu...
Architettura: luoghi comuni  Architetto != Analista  Architetto != Project Manager  Architettura != Design    Al limite… D...
Architettura: rappresentazioneL’architettura si rappresenta mediante   le view, che sono la rappresentazione   del sistema...
Requisito: una definizione1. Condizione o capacità che occorre   all’utente per risolvere un problema   o raggiungere un o...
Requisiti: la teoriaLa norma ISO9126, pubblicata nella  sua prima versione nel 1991, ha  definito il modello dei requisiti...
FunzionalitàCapacità di soddisfare esigenze  esplicite od implicite.    Idoneità = funzionalità appropriate per    specifi...
DisponibilitàCapacità di fornire una continuità di  servizio    Maturità = mancanza di interruzioni per    malfunzionament...
UsabilitàFacilità di utilizzo da parte degli utenti     Comprensione = acquisizione di     adeguato livello di conoscenza ...
EfficienzaCapacità di fornire prestazioni adeguate    Tempo Risposta = reattività agli stimoli    dell’utente    Utilizzo ...
ManutenibilitàFacilità di manutenzione correttiva e  evolutiva    Analizzabilità = facilità di diagnosi e    identificazio...
PortabilitàTrasferibilità da un ambiente all’altro     Adattabilità = facilità di adeguamento     ad un nuovo ambiente    ...
Recepire i requisitiLa mancanza di requisiti o la  mancanza della loro gestione sono  tra le cause principali del fallimen...
FINE
Upcoming SlideShare
Loading in...5
×

Idiomatic Domain Driven Design

1,225

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,225
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
28
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Idiomatic Domain Driven Design"

  1. 1. Idiomatic Domain Driven DesignAndrea Saltarelloandreas@manageddesigns.ithttp://blogs.ugidotnet.org/papehttp://twitter.com/andysal74 http://creativecommons.org/licenses/by-nc-nd/2.5/
  2. 2. DDDDomain Driven Design:• è un approccio alla realizzazione del software pensato per contenere la complessità• Non è un silver bullet
  3. 3. Ubiquitous LanguageE’ il linguaggio utilizzato nellediscussioni tra tutti i partecipanti alprogetto, nei diagrammi, nelladocumentazione e nel codice,diventando così comune a tutti gli attoriche partecipano alla realizzazione delsoftwareAttenzione ai dialetti!
  4. 4. Ubiquitous Language: falsi positiviNella 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 allarelazione tra significante e significato. Inaltre parole, il significante è la forma,fonica o grafica, utilizzata per richiamarelimmagine che, nella nostra mente, èassociata a un determinato concetto, osignificato.
  5. 5. Bounded ContextUn Bounded Context è un contestoall’interno del quale è valido unospecifico ubiquitous languageUn sistema può quindi essere unacomposizione di contesti differenti (es:web store, accountability,delivery&shipment …), comunicanti tradi loro mediante una Context MapOgni bounded context è (quasi) unsistema a sè
  6. 6. Architettura di DDD
  7. 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
  8. 8. IL DOMAIN LAYER
  9. 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. 10. Domain Model: precisazioni Non stiamo modellando la realtà assoluta, bensì un modello funzionale all’interno di un bounded context
  11. 11. Da 0 ad Aggregate E un insieme di elementi raggruppati in un’unità logica, quindi un grafo di oggetti Ha come radice lentità principale dellaggregato La radice è l’unico elemento che può essere referenziato fuori dai confini dell’aggregato Non è possibile agire direttamente sugli elementi senza passare dalla radice dellaggregato L’aggregate ha la responsabilità di implementare la propria logica
  12. 12. Domain Model
  13. 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 )
  14. 14. IRepository<T>
  15. 15. Repository++Quisquilie IT: Code Contracts Repository <3 IoC
  16. 16. APPLICATION LAYER
  17. 17. Application Layer: in teoriaApplication Layer: defines the jobs thesoftware is supposed to do and directs theexpressive domain objects to work outproblems. The tasks this layer isresponsible for are meaningful to thebusiness or necessary for interaction withthe application layers of other systems.This layer is kept thin. It does not containbusiness rules or knowledge, but onlycoordinates tasks and delegates work tocollaborations of domain objects in thenext layer down. It does not have statereflecting the business situation, but it canhave state that reflects the progress of atask for the user or the program.
  18. 18. Application Layer: in praticaE’ un catalogo di servizi in grado dieffettuare il mesh della logica presentenel domain layer esponendola allaapplicazione (es: presentation layer) inuna forma ad… alta digeribilità
  19. 19. PRESENTATION LAYER
  20. 20. Presentation Layer vs. DDDAvere a disposizione un domain layer«smart» è bello, ma costoso: Materializzazione degli oggetti Mesh della business logicTipicamente, si finisce per passare la vitaa «fare DTO»: Domain Layer <-> Application Layer Application Layer <-> Presentation Layer
  21. 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. 22. MVC: Falsi miti Lo scopo del Controller non è di separare la View dal Model. La responsabilità del Controller è di fare da mediatore tra lutente e lapplicazione, non tra la View e il Model. Nella “web suburbia” si dice MVC, ma si intende Model 2 [JSP specs]
  23. 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. 24. MVC @ Managed DesignsIn bottega usiamo ASP.NET MVC dalleprime CTP della v1, ed abbiamoraggiunto una struttura«standardizzata» dei progetti: Model 3 Layered Expression Trees
  25. 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)
  26. 26. Never mind the bollocks, here’s the Model 3
  27. 27. Layered Expression Trees (LET idiom)Facciamo un gioco: invece di definire un«botto» di DTO, facciamo che layer e servizi siscambino degliIQueryable<YourFavouriteDomainEntity>,facendo «emergere» la query e specificando laproiezione solo all’ultimo momento?L’espressione «Capra e cavoli» vi dice niente? 
  28. 28. C’mon Query LET’s go party (ah-ah-ah, yeah!)
  29. 29. MVVM Presentation ModelRepresent the state and behavior of thepresentation independently of the GUIcontrols used in the interfaceThe Presentation Model coordinates withthe domain layer and provides aninterface to the view that minimizesdecision making in the view.
  30. 30. MVVM vs. DDD• WPF: il ViewModel può consumare il domain layer senza limitazioni• Silverlight: il ViewModel non ha accesso al model
  31. 31. MVVM vs. Bottega51• WPF: il ViewModel può consumare il domain layer senza limitazioni• Silverlight: il ViewModel non ha accesso al model
  32. 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!
  33. 33. Appendix 1SOFTWARE ENGINEERING
  34. 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. 35. ISO/IEC 42010 fact sheetTitolo: IEEE Recommended Practice for Architectural Description of Software-Intensive SystemsScope: 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. 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. 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. 38. Architettura: luoghi comuni Architetto != Analista Architetto != Project Manager Architettura != Design Al limite… Design  Architettura
  39. 39. Architettura: rappresentazioneL’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. 40. Requisito: una definizione1. Condizione o capacità che occorre all’utente per risolvere un problema o raggiungere un obiettivo2. Condizione o capacità che deve essere raggiunta o posseduta dal sistema per soddisfare un contratto, standard, specifica o altro documento formale3. La rappresentazione documentata di una condizione o capacità (1 o 2)
  41. 41. Requisiti: la teoriaLa 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. 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. 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. 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. 45. EfficienzaCapacità di fornire prestazioni adeguate Tempo Risposta = reattività agli stimoli dell’utente Utilizzo risorse = utilizzo adeguato delle risorse del sistema
  46. 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. 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. 48. Recepire i requisitiLa mancanza di requisiti o la mancanza della loro gestione sono tra le cause principali del fallimento dei progettiRecepire i requisiti significa circoscrivere il problemaStrumenti utilizzati in bottega:• Use case• User story
  49. 49. FINE
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×