3. Leggere attentamente le
avvertenze…
(Quasi) Tutte le demo saranno basate su NSK, un
framework di e-commerce sviluppato in bottega e
scaricabile qui con licenza open source.
N.B.: NSK è come il galeone di Dylan Dog: non è
mai terminato, quindi non tutti i check-in sono
come la caramella Polo (cioè «riusciti col buco»
)
4. Andrea Saltarello! Chi era
costui?
1. C.T.O. di Managed Designs, alla ricerca della
«sostenibilità dello sviluppo software»
– Il cliente «deve» essere soddisfatto e pagare
– Il fornitore «deve» avere un margine ragionevole
– Il team «deve» essere soddisfatto del proprio lavoro
2. Fondatore e presidente di UGIdotNET: ho
bisogno di condividere esperienze a causa del bullet
precedente
3. (Co)Autore di .NET: Architecting Applications
for the Enterprise di Microsoft Press
– Il #NAAE è il mio giornale di bordo, nel quale (nel 2008)
ho cercato di «sintetizzare» i punti 1 e 2
5. Once upon a time…
1. Acquistai il [P of EAA] a febbraio 2003, lo lessi
e… «estiqaatsi?»
2. Acquistai il «Blue Book» appena uscito (2004),
lo lessi e… «estiqaatsi?»
3. In poche parole: come «passo» dal libro al
mondo reale?
6. Innanzitutto…
• Ubiquitous Language
• Ubiquitous Language
• Ubiquitous Language
• Ubiquitous Language
• Ubiquitous Language
• Ubiquitous Language
• Ubiquitous Language
10. Blue Book: Architettura (2/2)
• è una layered architecture
• i layer Presentation e Infrastructure
compaiono «per sport» nel diagramma
• i layer Application e Domain costituiscono
quella che tipicamente chiamiamo «business
logic»
– Domain: logica invariante rispetto ai casi d’uso
– Application: logica specifica ai casi d’uso
12. Domain layer: Key Concepts
• Il Domain Layer contiene la domain logic ed è composto
da
– Model: Entità (identità e stato) e Valori (solo stato)
– Servizi
• Il Model è «both data and behaviour» (cit.)
• La persistenza del Model è gestita da Repository
• Le istanze delle entità di dominio sono costruite da
Factory
• Entità e Valori a runtime formano dei grafi di oggetti. I
grafi dotati di “dignità propria” sono chiamati
Aggregate e il sistema (es: i Repository) si “impegna”
a gestirli correttamente ed atomicamente
14. Da 0 ad Aggregate
• E' un insieme di elementi raggruppati in un’unità
logica, quindi un grafo di oggetti
• Ha come radice l'entità principale dell'aggregato
• La radice è l’unico elemento che può essere
referenziato fuori dai confini dell’aggregato
• Non è possibile agire direttamente sugli elementi
senza passare dalla radice dell'aggregato
• L’aggregate ha la responsabilità di implementare la
propria logica
16. One More Thing… (cit.)
E’ DDD, non «Il Signore degli Anelli», quindi:
Assert.IsFalse(OneModelToRuleThemAll);
17. Repository pattern: in teoria
A system with a complex domain model often benefits from a
layer, such as the one provided by Data Mapper (165), that
isolates domain objects from details of the database access
code. In such systems it can be worthwhile to build another
layer of abstraction over the mapping layer where query
construction code is concentrated.This becomes more
important when there are a large number of domain classes
or heavy querying. In these cases particularly, adding this layer
helps minimize duplicate query logic.
…
You can also find a good write-up of this pattern in Domain
Driven Design.
18. Repository pattern: in pratica
Mediates between the domain and data mapping layers
using a collection-like interface for accessing domain
objects.
Ricapitolando:
• Interfaccia “collection like”
• Gestisce la persistenza degli Aggregate
• LINQ! (siamo dei buongustai )
20. Application Layer: in teoria
Application Layer: defines the jobs the software is
supposed to do and directs the expressive domain
objects to work out problems. The tasks this layer is
responsible for are meaningful to the business or
necessary for interaction with the application layers
of other systems. This layer is kept thin. It does
not contain business rules or knowledge, but only
coordinates tasks and delegates work to
collaborations of domain objects in the next layer
down. It does not have state reflecting the business
situation, but it can have state that reflects the
progress of a task for the user or the program.
21. Application Layer: in pratica
E’ un catalogo di servizi in grado di effettuare il
mesh della logica presente nel domain layer
esponendola alla applicazione (es: presentation
layer) in una forma ad… Alta digeribilità.
22. DDD vs Real World
Avere a disposizione un domain layer «smart» è bello,
ma costoso:
– Materializzazione degli oggetti
– Mesh della business logic
Tipicamente, si finisce per passare la vita a «fare
DTO»:
– Application Layer <-> Presentation Layer
– («ma anche» cit.) Domain Layer <-> Application Layer
23. Layered Expression Trees (LET idiom)
Facciamo un gioco: invece di definire un «botto» di
DTO, facciamo che layer e servizi si scambino degli
IQueryable<YourFavouriteDomainEntity>, facendo
«emergere» la query e specificando la proiezione solo
all’ultimo momento?
L’espressione «Capra e cavoli» vi dice niente?
P.S.: Si, «botto» è un ordine di grandezza del S.I. Kilo-
>Mega->Giga->Tera->Peta->Botto
25. LET idiom feat. Ubiquitous Language
LET aumenta la pervasività dell’Ubiquitous Language nel
codice:
recommendedProducts = (from p in CatalogServices.GetAvailableProductsOnSale()
orderby p.UnitsInStock descending
select new ProductDescriptor
{
Id = p.Id,
Name = p.Name,
UnitPrice = p.UnitPrice,
UnitsInStock = p.UnitsInStock,
}).Take(3);
Questa query è «quasi» scritta nel linguaggio del Domain
Expert
27. Command Query Responsibility
Segregation
Command and Query Responsibility Segregation (CQRS)
originated with Bertrand Meyer’s Command and Query
Separation Principle. Wikipedia defines the principle as:
It states that every method should either be a command that performs
an action, or a query that returns data to the caller, but not both.
Command and Query Responsibility Segregation uses the same
definition of Commands and Queries that Meyer used and
maintains the viewpoint that they should be pure. The
fundamental difference is that in CQRS objects are split into two
objects, one containing the Commands one containing the
Queries.
[Fonte: http://cqrsinfo.com/documents/cqrs-introduction/ ]
30. Books & Publications
[DDD] Domain Driven Design, Eric Evans ,
Addison-Wesley
[P of EAA] Pattern of Enterprise
Application Architecture, Martin Fowler,
Addison-Wesley
[NAAE] Microsoft .NET: Architecting
Applications for the Enterprise, Andrea
Saltarello & Dino Esposito, Microsoft Press
[NSK] NSK, http://nsk.codeplex.com
