Your SlideShare is downloading. ×
Idiomatic Domain Driven Design
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Idiomatic Domain Driven Design

1,207
views

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,207
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
28
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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. DDDDomain Driven Design:• è un approccio alla realizzazione del software pensato per contenere la complessità• Non è un silver bullet
  • 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. 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. 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. Architettura di DDD
  • 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. IL DOMAIN LAYER
  • 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 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. Domain Model
  • 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. IRepository<T>
  • 15. Repository++Quisquilie IT: Code Contracts Repository <3 IoC
  • 16. APPLICATION LAYER
  • 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. 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. PRESENTATION LAYER
  • 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. 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 lutente e lapplicazione, 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 DesignsIn bottega usiamo ASP.NET MVC dalleprime CTP della v1, ed abbiamoraggiunto 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)
  • 26. Never mind the bollocks, here’s the Model 3
  • 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. C’mon Query LET’s go party (ah-ah-ah, yeah!)
  • 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. 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!
  • 33. Appendix 1SOFTWARE ENGINEERING
  • 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 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. 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: 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. 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. 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. 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. EfficienzaCapacità 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 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. FINE

×