Il documento discute l'importanza del Domain Driven Design (DDD) per tradurre la complessità del dominio applicativo in un modello ad oggetti, evidenziando il ruolo centrale del modello e la necessità di un linguaggio comune tra sviluppatori e esperti di dominio. Viene descritto come l'approccio DDD sia utile in contesti con logiche di business complesse e in continua evoluzione, mentre può non essere vantaggioso in progetti più semplici. Infine, si citano diversi concetti chiave legati al DDD, come entità, aggregati, repository e servizi, sottolineando l'importanza di un approccio collaborativo tra i membri del team.

1. Luca Milan
http://fewbit.com
info@fewbit.com

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