Abbiamo il nostro splendido Domain Model, e possiamo passare la vita a definire DTO per usarlo in modo “sostenibile”. Oppure possiamo metterlo (un po’) in disparte ed adottare CQRS, ammesso che non ci venga mai da dire: “che spreco”. Oppure possiamo optare per una terza via idiomatica: Layered Expression Trees. Parliamone.
Layered Expression Trees: una terza via (idiomatica) verso il DDD
1. Layered Expression Trees: una
terza via (idiomatica) verso il DDD
Andrea Saltarello
Software Architect @ Managed Designs
andysal@gmail.com
http://twitter.com/andysal74
http://blogs.ugidotnet.org/pape
http://creativecommons.org/licenses/by-nc-nd/2.5/ managed/designs
4. Architettura di DDD
è 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 per i casi d’uso
Application: logica specifica ai casi d’uso
managed/designs
5. 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.
managed/designs
6. 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à
managed/designs
7. Real world DDD
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»:
Domain Layer <-> Application Layer
Application Layer <-> Presentation Layer
managed/designs
8. 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?
managed/designs
10. Books & Publications
[DDD] Domain Driven Design, Eric Evans , Addison-
Wesley
[P of EAA] Pattern of Enterprise Application
Architecture, Martin Fowler, Addison-Wesley
[NSK] NSK, http://nsk.codeplex.com
managed/designs
Notes de l'éditeur
Abbiamo il nostro splendido Domain Model, e possiamo passare la vita a definire DTO per usarlo in modo “sostenibile”. Oppure possiamo metterlo (un po’) in disparte ed adottare CQRS, ammesso che non ci venga mai da dire: “che spreco”. Oppure possiamo optare per una terza via idiomatica: LayeredExpressionTrees. Parliamone.