Luca Milan

Transcript

1 Luca Milan

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 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 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 Domain Model An object model of the domain that incorporates both behavior and data da Fowler Una classe.net incarna un object model Attenzione: Classe!= Oggetto public class Ordine{ public string Cliente{get;set;} public void MarcaComeCompleto(){ Stato = StatoOrdine.Completo; } 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 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 Parte di Catalogo di un domain model per un sistema di e-commerce

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 Ubiquitous Language Entity Value Object Repository Service Aggregates Factories Specification / Queries Context (Boundary / Map) Attori della DDD Unit Of Work Inversion Of Control Object Relational Mapping Aspected Oriented Programming Contract By Design TDD, BDD OO tecniques, SOLID principles Refactoring Patterns e tecniche collegate

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 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 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 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 objectoriented 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 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 Possiamo usare l approccio DDD anche con altri tipi di architetture di classe enterprise: Con SOA vedi In scenari distribuiti come Distributed DDD vedi Con REST vedi n-patterns.aspx

16 A97EC-6B79-42C1-9DAF-D8D00D8C7759/guisa.pdf

17