Luca Milanhttp://fewbit.cominfo@fewbit.com

“ 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 alloscopo (nessun virtuosismo concettuale dobbiamo esserepragmatici).

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.

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

Domain Model◦ “An object model of the domain that incorporates both

behavior and data” da Fowler

◦ Attenzione:Classe != Oggetto

Una volta creati gli oggetti possiamo collegarli tramite gerarchiee relazioni ed assegnarli ruoli e responsabilità. Ciò significa

formare la rete interconnessa (grafo) del pattern di Fowler.

public class Ordine{public string Cliente{get;set;}public void MarcaComeCompleto(){

Stato = StatoOrdine.Completo;}public IList<Linee> {get;set;}

}

Una classe .NET incarna un object model

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!!!

Parte di Catalogo di un domain model per un sistema di e-commerce

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.

Attori della DDD Patterns e tecniche collegate

Ubiquitous Language

Entity

Value Object

Repository

Service

Aggregates

Factories

Specification / Queries

Context (Boundary / Map)

Unit Of Work Inversion Of Control Object Relational Mapping Aspected Oriented

Programming Contract By Design TDD, BDD OO tecniques, SOLID

principles Refactoring

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..

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“

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”

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à.

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ù oggettidel dominio (entity,value objects,repository). Es. La modifica di un ordinenon può essere delegata ad un singolo comportamento dell’entità Ordine, meglio creare un servizio IOrderModify.Execute(params).

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/application-patterns.aspx

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/63DA97EC-6B79-42C1-9DAF-D8D00D8C7759/guisa.pdf