1 / 45

Domain Driven Design: Overview Speaker: Giancarlo Sudano

Domain Driven Design: Overview Speaker: Giancarlo Sudano. About me:. Giancarlo Sudano ( alias janky ). Software Architect in Objectway Fondatore di GUISA www.guisa.org Blog su Ugidotnet: http://blogs.ugidotnet.org/janky Email: giancarlo.sudano@gmail.com giancarlo.sudano@objectway.it.

onofre
Download Presentation

Domain Driven Design: Overview Speaker: Giancarlo Sudano

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Domain Driven Design: Overview Speaker: Giancarlo Sudano

  2. About me: Giancarlo Sudano(aliasjanky) Software Architect in Objectway Fondatore di GUISA www.guisa.org Blog su Ugidotnet: http://blogs.ugidotnet.org/janky Email: giancarlo.sudano@gmail.comgiancarlo.sudano@objectway.it

  3. Agenda • Domain Model • Domain Driven Design • Conceptual Map • Layering • Esempi reali: Web Client Software Factory

  4. DOMAIN MODEL

  5. Un po di discipline...

  6. Business Requirement Business Requirement Use Case Model Processo di vendita (testo) Processo d’Ordine (testo)

  7. Business Modeling Business Requirement Business Modeling Use Case Model Domain Model 1 Order Customer Processo di vendita (testo) Processo d’Ordine (testo) 1..* 1..* Product Gli Use case, i termini, i concetti ispirano il Domain Model

  8. Software Design Business Modeling Software Design Domain Model Object Model 1 Order Customer 1..* 1..* Product I concetti del Dominio ispirano nomi e comportamenti delle classi del software

  9. Design del Domain Layer Classificazione fatta da Fowler [PoEAA 2004] Transaction Script: Principalmente il layer sarà modellato con delle procedure che prendono l’input dal layer di presentation, li processano e eventualmente trasmettono manipolazioni sui database. Table Module: Serie di classi che gestiscono la logica di business per tutte le righe sul database di una particolare entità. Domain Model: Serie di classi ispirate al modello analitico che gestiscono sia stato che comportamento. Una singola istanza rappresenta una singola entità.

  10. Riepilogo delle definizioni • Modello analitico: concettualizzazione del problema di business • Domain Layer: Strato di software che rappresenta l’implementazione del modello analitico • Domain Layer patterns: metodologie per implementare i problemi di business • Transaction script • Table Module • Domain Model

  11. Domain Driven Design

  12. Formalizzazione fatta da Eric Evans 2003/04 nel suo libro “Domain Driven Design: Tackling Complexity In The Heart Of Software” Scopo del libro: “…To describe and build a vocabulary about the very art of domain modeling…” ...tutto cominciò...

  13. http://domaindrivendesign.org Informazioni Interviste Articoli Discussioni Case Stories Esempi Domain Driven Design: Il portale

  14. La DDD è un mindset, cioè una serie di principi e priorità, atte ad accelerare la progettazione software che ha a che fare con domini di particolare complessità. Domain Driven Design: Definizione

  15. Il modello analitico (cioè il risultato del lavoro degli analisti) è uno strumento di sola comprensione. Un analista poi può usare UML per la visualizzazione del modello stesso.  Il modello non porterà nessun dettaglio implementativo ai fini di non inquinare la comprensione. Presupposti per la nascita di DDD

  16. l'implementazionedi un modello molte volte può allontanarsi notevolmente dalla sua iniziale descrizione. La Domain Driven Design è una disciplina di progettazione atta quindi a tenere costantemente vicini/connessi il modello analitico che il modello implementativo.  Quindi...

  17. Esempio classico di discostamento

  18. La prima Conceptual Map di DDD

  19. Entity e ValueObject

  20. Troppa logica nelle entity? • In generale si tende ad aggiungere solo i metodi essenziali ad una entity. • Inserire troppa logica all’interno di una entity: • + Complessità • Manutenibilità • Chiarezza, Espressività

  21. Service Una classe Service modella, non tanto una entità di dominio, ma una regola di business Qualcosa che il software “deve fare” (operazione) e che non necessariamente coincide con uno stato

  22. Business Rules Restrictions: Un cliente non può inserire più di tre richieste d’ordine caricate sul suo credit account. Heuristics: Gli ordini di un cliente con uno stato preferenziale verranno evasi immediatamente. Computations: Il volume di ordini annuale di un cliente deve essere calcolato dal totale delle vendite chiuse entro la chiusura dell’anno fiscale aziendale. Inference: Un cliente deve essere considerato preferenziale se ha almeno 5 ordini superiori a 1000 euro. Timing: Un cliente verrà archiviato se non effettua ordini per 36 mesi consecutivi. Triggers:Quando un ordine è stato spedito, una notifica di “Send advance” deve essere notificata ad una serie di sottoscritti

  23. Tipi di Services

  24. Come distribuire logica tra Service e Entity? • Una Entity con troppe responsabilità rischia di perdere in chiarezza concettuale. • Entity troppo cariche sono di difficile manutenzione, refactoring e testing. • Le operazioni di business, sono spesso legate ad altre entity. Esprimere queste operazioni come metodo di una Entity, aumenta la sua dipendenza da altri oggetti

  25. Service dipendenti da classi (non da id)

  26. Factory Responsabilità di creare e assemblare oggetti particolarmente complessi. La logica di creazione di grafi immersa nel costruttore stesso, potrebbe non essere una “buona idea”.

  27. Repository Responsabilità del ciclo di vita delle Entity. Responsabilità infrastrutturali di persistenza quali Identity Map, Cache.

  28. Layering

  29. Contesto classico • Isolare il codice dalla interfaccia utente • Isolare il codice di accesso al database

  30. Soluzione classica Presentation Business Logic Data Access

  31. Soluzione classica WinForm Compact Framework Web Form WPF Form Business Logic Data Access(database A) Data Access(database B)

  32. Non se ne può più...andiamo oltre 

  33. Dominio Domain Model quanto più indipendente da tutte le altre parti del sistema. E’ buona norma rendere il DM facilmente testabile, modificabile. Minimizzare la dipendenza anche dalle API di .NET. Presentation Layer Riutilizzo più pesante del codice tra una Presentation Layer ed un altro Migliorare le capacità di Test delle View e della logica di Flusso Servizi: Distinzione tra servizi infrastrutturali e applicativi Requisiti più alti

  34. Isolamento: Layering User Interface (Presentation Layer) Responsible for presenting information to the user and interpreting user commands. Application Layer This is a thin layer which coordinates the application activity. It does not contain business logic. It does not hold the state of the business objects, but it can hold the state of an application task progress. Domain Layer This layer contains information about the domain. This is the heart of the business software. The state of business objects is held here. Persistence of the business objects and possibly their state is delegated to the infrastructure layer. Infrastructure Layer This layer acts as a supporting library for all the other layers. It provides communication between layers, implements persistence for business objects, contains supporting libraries for the user interface layer, etc.

  35. Soluzione Presentation Coordina le attività dell’applicazione.Non contiene logica di business.Non gestisce lo stato delle Entity, ma gestisce lo stato dell’applicazione e dei progresso dei taskPuò eseguire Processi di Business e Servizi in seguito a comandi dalla UI o a Eventi Esterni UI Process Business Logic Data Access

  36. Confusioni sui nomi di layer? Martin Fowler DNA, J2EE Brown Eric Evans Presentation Presentation Presentation Presentation Presentation = UI Process ... Controller/ Mediator Application Controller Application = Business Business Domain Domain Domain = Data Access Data Access Data Access Data Source Infrastructure =

  37. Soluzione Presentation UI Process Business Process Security Service Altri Service Business Rules Validations Data Access Entity (detto anche Core)

  38. Soluzione Presentation UI Process Business Process Security Service Altri Service Business Rules Validations Data Access Entity (detto anche Core)

  39. Layered Applications Service Gateway

  40. CrossCutting Utility ClassException Handling, Logging, Security Presentation Layer UserInterface Process Layer CAB , CWAB, Acropolis , MonoRail, Workflow Foundation Authorization Authentication Business Process Layer Workflow Foundation, BizTalk, Spring Validation, Validation Application Block Domain Layer AOP FrameworkSpring.net, Policy Injection Application Block Log e Trace Transaction Management DataAccess Layer Service Layer Dependency Injection Framework(Spring.NET, Windsor) ORM NHibernate, Linq to SQL, Genome Legacy WebServices LDAP EnterpriseServices Database

  41. Altre navigation maps

  42. Supple Design Patterns Eric Evans: Domain Driven Design [2006]

  43. Model Integrity Patterns Eric Evans: Domain Driven Design [2006]

  44. Libro: Domain Driven Design: Tackling Complexity In The Heart Of Software [Eric Evans 2003] Libro: Applying Domain-Driven Design and Patterns [Jimmy Nilsson 2006] Libro: Domain Driven Design Quickly [InfoQ 2006] (gratuito, scaricabile da internet) http://domaindrivendesign.org/ Seguite il mio blog:iniziativa: “Domain Model e Enterprise Application” Riferimenti

More Related