Approccio Pratico al Domain Driven Design

5,114 views

Published on

Approccio Pratico al Domain Driven Design

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

No Downloads
Views
Total views
5,114
On SlideShare
0
From Embeds
0
Number of Embeds
36
Actions
Shares
0
Downloads
89
Comments
0
Likes
7
Embeds 0
No embeds

No notes for slide

Approccio Pratico al Domain Driven Design

  1. 1. Luca Milan http://fewbit.com info@fewbit.com
  2. 2. “ At its worst business logic can be very complex. Rules and logic describe many different cases and slants of behavior, and it’s this complexity that objects were designed to work with. A Domain Model creates a web of interconnected objects, where each object represents some meaningful individual, whether as large as a corporation or as small as a single line on an order form” Io leggo: usiamo tecniche OO per tradurre la complessità del dominio applicativo in un modello ad oggetti utile allo scopo (nessun virtuosismo concettuale dobbiamo essere pragmatici).
  3. 3.  Una disciplina che aiuta lo sviluppatore ad consolidare le logiche di business (complesse e in evoluzione) di un dominio applicativo in un Modello ad Oggetti grazie al paradigma OO .  Un insieme di regole e principi che pone il Modello ad Oggetti come centro del processo di sviluppo.  Uno stile architetturale che realizza un disaccoppiamento tra il Modello ad Oggetti e gli altri strati software rendendolo totalmente autonomo e indipendente.
  4. 4.  Possiamo farlo quando: ◦ Il processo di sviluppo è iterativo. Miglioreremo la conoscenza del dominio passo dopo passo grazie all’aiuto degli esperti del dominio. ◦ Le logiche di business del domino sono complesse ed evolvono continuamente nel tempo. ◦ Conosciamo bene la programmazione OO ed abbiamo familiarità con concetti come Refactoring, IOC, Persistence Ignorance (PI), principi SOLID, ecc..  Non conviene usare la DDD quando: ◦ I progetti sono semplici (un blog, un piccolo e-commerce) e non subiscono evoluzioni nel tempo. ◦ Applicazioni di pura reportistica o ETL o simili
  5. 5.  Domain Model ◦ “An object model of the domain that incorporates both behavior and data” da Fowler Una classe .NET incarna un public class Ordine{ object model public string Cliente{get;set;} public void MarcaComeCompleto(){ ◦ Attenzione: Stato = StatoOrdine.Completo; } Classe != Oggetto public IList<Linee> {get;set;} } Una volta creati gli oggetti possiamo collegarli tramite gerarchie e relazioni ed assegnarli ruoli e responsabilità. Ciò significa formare la rete interconnessa (grafo) del pattern di Fowler.
  6. 6.  Bounded Context (or Context) ◦ “The delimited applicability of a particular model. BOUNDING CONTEXTS gives team members a clear and shared understanding of what has to be consistent and what can develop independently” da domaindrivendesign.org Rappresentano i confini (variabili) del dominio e devono essere ben marcati. Al di fuori di essi dobbiamo lasciare tutta la complessità non utile ai nostri scopi (funzionali ed applicativi). Non perdiamo la direzione!!!
  7. 7.  Parte di Catalogo di un domain model per un sistema di e-commerce
  8. 8.  Spesso i domain model non seguono le regole indicate da Fowler ed Evans, in questo caso Fowler identifica un anti-pattern: l’Anemic Domain Model  I sintomi di un dominio anemico sono a livello di classe: 1. Ad una 1 classe corrisponde una 1 tabella 2. Non ci sono metodi solo getters e setters 3. La logica anziché sui metodi viene incapsulata nei setters In questi casi dobbiamo rivitalizzare il dominio.
  9. 9.  Ubiquitous Language  Unit Of Work  Entity  Inversion Of Control  Value Object  Object Relational Mapping  Aspected Oriented  Repository Programming  Service  Contract By Design  Aggregates  TDD, BDD  Factories  OO tecniques, SOLID  Specification / Queries principles  Context (Boundary / Map)  Refactoring Attori della DDD Patterns e tecniche collegate
  10. 10.  Sviluppatori ed esperti del dominio devono collaborare tra loro. Per farlo al meglio devono trovare un linguaggio comune semplice ed intuitivo con cui poter dialogare (no termini tecnici, no termini di business) . Paginare, Schedulare, Indicizzare, Disaccoppiare CGA, Mandato ad Assicurare, ecc..
  11. 11.  Dal libro di Eric Evans: 1. "An Entity is an Object that represents something with continuity and identity. An entity is tracked through different states and implementations.“ 2. "An object that represents a descriptive aspect of the domain with no conceptual identity“
  12. 12.  Dal libro di Eric Evans “First we need an abstraction for encapsulating references within the [domain] model. An Aggregate is a cluster of associated [domain] objects that we treat as a unit for the purpose of [ensuring consistency of] data changes. Each Aggregate has a root and a boundary. The root is a single, specific Entity contained in the Aggregate”
  13. 13.  E’ uno dei concetti più dibattuti Fowler dice: “A Repository mediates between the domain and data mapping layers, acting like an in-memory domain object collection. Client objects construct query specifications declaratively and submit them to Repository for satisfaction. Objects can be added to and removed from the Repository, as they can from a simple collection of objects, and the mapping code encapsulated by the Repository will carry out the appropriate operations behind the scenes. Conceptually, a Repository encapsulates the set of objects persisted in a data store and the operations performed over them, providing a more object- oriented view of the persistence layer. Repository also supports the objective of achieving a clean separation and one-way dependency between the domain and data mapping layers” Parla il linguaggio del domain model (no DTO no DAO) ed è agnostico rispetto ai meccanismi di persistenza utilizzati dall’applicazione. Rafforza il concetto di uguaglianza per Identità (non by reference), il repository restituisce la stessa istanza di oggetto se l’oggetto ha la stessa identità.
  14. 14.  Dal libro di Eric Evans “A SERVICE is an operation offered as an interface that stands alone in the model, without encapsulating state, as ENTITIES and VALUE OBJECTS do.“ Un servizio si occupa di coordinare azioni che coinvolgono uno o più oggetti del dominio (entity,value objects,repository). Es. La modifica di un ordine non può essere delegata ad un singolo comportamento dell’entità Ordine, meglio creare un servizio IOrderModify.Execute(params).
  15. 15.  Possiamo usare l’approccio DDD anche con altri tipi di architetture di classe enterprise: ◦ Con SOA vedi http://www.udidahan.com/ ◦ In scenari distribuiti come Distributed DDD vedi http://codebetter.com/blogs/gregyoung/ ◦ Con REST vedi http://blogs.msdn.com/jmeier/archive/2009/01/21/applicatio n-patterns.aspx
  16. 16.  http://www.infoq.com/presentations/model-to-work- evans  http://domaindrivendesign.org/books  http://www.infoq.com/interviews/jimmy-nilsson- domain-driven-design  http://domaindrivendesign.org/  http://download.microsoft.com/download/6/3/D/63D A97EC-6B79-42C1-9DAF-D8D00D8C7759/guisa.pdf

×