Loosely Coupled Complexity <ul><li>Unleash the power of your Domain Model using CQRS & Event Sourcing </li></ul>[email_add...
About me <ul><li>In the IT field since ZX Spectrum </li></ul><ul><li>Generally in  large scale projects  (I might be  bias...
<ul><li>@avanscoperta </li></ul><ul><li>www.avanscoperta.it </li></ul><ul><li>avanscoperta.wordpress.com </li></ul><ul><li...
Questi 3 tipi hanno qualcosa di veramente interessante da dire...
Cosa c’è che non va? UI Remote facade Application Services DTO DTO ORM
niente
Thank you <ul><li>[email_address] </li></ul><ul><li>http://ziobrando.blogspot.com </li></ul><ul><li>twitter: ziobrando </l...
- Quale gobba?
Quante  assunzioni  stanno guidando le nostre decisioni?
Proviamo ancora... UI Remote facade Application Services DTO DTO ORM
<ul><li>Anaemic Domain Model </li></ul><ul><li>i DTO? </li></ul><ul><li>Ottimizzazione query su ORM </li></ul><ul><li>Temp...
<ul><li>Abbiamo veramente bisogno di... </li></ul><ul><ul><li>un Domain Model? </li></ul></ul><ul><ul><li>un Database? </l...
Anaemic Domain Model
Non tutti i regali sono necessariamente graditi...
Vantaggi dell’Anaemic Domain Model 1) Il codice business è localizzato in un solo posto: Più facile da leggere per  svilup...
Svantaggi dell’Anemic Domain Model Triste come un pasto in ospedale difficile da matenere difficile da testare alimenta la...
<ul><li>Progettate la vistra applicazione partendo dal data model </li></ul><ul><li>Create il vostro domain model via reve...
<ul><li>Non farò più il reverse engineering del data model per creare un domain model </li></ul>
<ul><li>Non farò più il reverse engineering del data model per creare un domain model </li></ul><ul><li>Non farò più il re...
<ul><li>Non farò più il reverse engineering del data model per creare un domain model  </li></ul><ul><li>Non farò più il r...
<ul><li>Non farò più il reverse engineering del data model per creare un domain model </li></ul><ul><li>Non farò più il re...
<ul><li>Non farò più il reverse engineering del data model per creare un domain model </li></ul><ul><li>Non farò più il re...
<ul><li>Non farò più il reverse engineering del data model per creare un domain model </li></ul><ul><li>Non farò più il re...
Come dovremmo implementare un Domain Model? Fate in modo che il codice parli lo  Ubiquitous Language Proteggete il vostro ...
Anemic Domain Model
Rich domain model
TDD  e  DDD Riscritture frequenti Exploratory coding Domain Objects minimali Focus sugli Unit Tests Tiny Domain Objects Ti...
Aggregate Un gruppo di oggetti  naturalmente vicini Unità di consistenza  nel domain model modificati nella  stessa transa...
Aggregati multipli
Ma la duplicazione non era il male? <ul><li>Se pensiamo ai “dati” allora  ...c’è duplicazione </li></ul><ul><li>Se pensiam...
Alla fine è piuttosto semplice
Perchè complicarsi la vita?
Hmm... Una volta che l’accoppiamento tra gli aggregati è ridotto... potrei anche pensare di scegliere una strategia di per...
dalla cara vecchia architettura... UI Remote facade Application Services DTO DTO ORM
La visione DDD classica UI Remote facade Application Services DTO DTO ORM bounded contexts aggregate boundaries thin appli...
Portiamo i Domain Objects alla UI? <ul><li>I DTO non piacciono a nessuno... </li></ul><ul><li>Alcuni tool lo permettono! (...
Come implementereste queste? As a  Marketing Office I want to  assign discount points to customer on every purchase In ord...
Eventi e coordinamento fra aggregati <ul><li>Operazione che coinvolgono più aggregati non dovrebbero essere nella stessa  ...
Domain Event <ul><li>nello  Ubiquitous Language , sono  Azioni Completate : verbi al passato. </li></ul>
Rispondere asincronamente agli eventi <ul><li>Non dimentichiamo:  il legame vero tra le azioni è definito dal business!!! ...
a qualcuno ricorda SOA ? ...proviamo a disegnare le cose diversamente e pensare alla “granularità dei servizi” ...proviamo...
Command/Query Responsibility  Segregation Segregation
 
perché trovare un  compromesso ?
Partendo dal piccolo... <ul><li>Command/Query Separation  era un  principio OOD  incluso in DDD </li></ul><ul><ul><li>acce...
! Di solito indirizzati ad  entità singole il  comportamento  è importante  la  Flessibilità  è importante Command
? Grosse quantità di  dati Non c’è comportamento le  Prestazioni  sono importanti Disponibili numerosi  componenti off-the...
da questo... UI Remote facade Application Services DTO DTO ORM
...a questo UI Remote facade Application Services ORM Remote facade Thin Read Layer DTO DTO
Un percorso separato per comandi inviati al Domain Model Un percorso separato per recuperare Dati
Querying <ul><li>Date un’occhiata ai vostri  utenti , cosa interessa loro veramente? </li></ul><ul><ul><li>Non è  cercare,...
Staleness <ul><li>È  veramente  un  problema ? </li></ul><ul><li>Importa veramente se i dati sono... </li></ul><ul><ul><li...
Sono solo dati <ul><li>Non c’è  comportamento  in quello che vediamo. </li></ul><ul><li>Abbiamo veramente bisogno di  ogge...
Query-Only Architecture <ul><li>Sono solo dati: no comportamento... </li></ul><ul><ul><li>=> perché non andare  dritti sul...
Anche i dati  stale  possono <ul><li>... fornire informazioni utili per la  validazione preliminare dei comandi </li></ul>...
...meno comandi che falliscono <ul><li>Se la maggio parte dei nostri comandi avrà successo... </li></ul><ul><li>... c’è ve...
Catturare le intenzioni dell’utente <ul><li>Sappiamo realmente  cosa l’utente vuole fare con la nostra applicazione ? </li...
Commands != Entities <ul><li>Non c’è molto in comune... </li></ul><ul><ul><li>per quale motivo devo mostrarle all’utente? ...
Write-only model <ul><li>Il domain model  non  è usato per  recuperare  o  mostrare  dati. </li></ul><ul><ul><li>Le relazi...
Persisting the model <ul><li>Abbiamo  veramente  bisogno di rendere persistenti  tutti i dati ? </li></ul><ul><li>Abbiamo ...
UI Remote facade Application Services ORM Remote facade Thin Read Layer DTO Commands
voilà UI Remote facade Application Services ORM? Remote facade Thin Read Layer DTO publish subscribe Specialized data mode...
un interessante side effect <ul><li>... meno collections ... </li></ul><ul><li>=> meno impatto sulla memoria </li></ul><ul...
The paper-based system Molti tipi di azienda nascono prima dei computers Le transazioni non sono un problema bisiness I Da...
Event Sourcing
Quindi ...cosa fa il nostro Domain Model?  <ul><li>fondamentalmente  risponde a messaggi autocontenuti provenienti dall’es...
La singola sorgente di verità <ul><li>Un tempo era la  carta ...  </li></ul><ul><li>ora sono gli  Eventi </li></ul>
voilà UI Remote facade Application Services ORM ? Remote facade Thin Read Layer DTO publish subscribe Events Events
Dobbiamo tenere lo stato nelle Entities? <ul><li>Abbiamo  tutte le informazioni necessarie  nella  Event Queue </li></ul><...
Aggregati ed eventi <ul><li>Gli aggregati tengono traccia degli eventi e derivano il proprio comportamento di conseguenza ...
Che succede se... <ul><li>deriviamo lo  stato  degli  Aggregati  dalla  sequenza degli eventi   che sono avvenuti in un si...
 
Gli aggregati disaccoppiati permettono  semplificazioni nello sviluppo La terra delle opportunità Polyglot persistence mig...
Una cosa alla volta Non è detto che abbiate bisogno di tutto Ogni step è un miglioramento Anche in piccole architetture .....
 
 
References <ul><li>http://groups.google.com/group/dddcqrs </li></ul><ul><li>http://cqrs.wordpress.com/ </li></ul><ul><li>h...
Thank you <ul><li>[email_address] </li></ul><ul><li>http://ziobrando.blogspot.com </li></ul><ul><li>twitter: ziobrando </l...
Upcoming SlideShare
Loading in …5
×

Loosely Coupled Complexity - Unleash the power of your domain model

783 views

Published on

Common software architectures are full of well-established assumptions. But some of them are flawed, no longer valid or relevant. Changing the rules of the game using DDD, CQRS and Event Sourcing can lead to systems which are more scalable, maintainable and performing. And which are fun to code as well.

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
783
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
14
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • And that’s the company I started one year ago.
  • Disclaimer: this is second-hand talk. 99% of the ideas come from these three guys. In the last couple of years a little revolution has being going on in the DDD community: Udi Dahan (left) and Greg Young (right) have brought new ideas in the DDD landscape.
  • Ok, let&apos;s start from a familiar architecture, what&apos;s wrong with that?
  • Ok, if that’s the answer... If you really like that and think that’s the best possible world... then I don’t have so much to tell you.
  • On the other hand, if you really think about it, there are a few things in your familiar architecture that you’ve been probably too used to. Enough to forget that there might be a different way.
  • Let’s try again, with a clear mind.
  • Here are some of the things we might not like.
  • And here are some of the questions we might ask ourselves
  • Ok, let’s start from the anaemic domain model: in the picture red is where the logic is. As you might see, there’s not so mouch in the Order class...
  • How did we get there? Well sometimes it’s just a matter of features that came for free, like a tool that allows you to reverse engineering your database to create domain classes.
  • Ok, but anaemic domain model is probably the dominant pattern throughout the world, so it must have some advantages: let’s dig into them.
  • Let’s look at the drawbacks instead... in two words it provides all the architetural complexity of an OOP system with the advantages in maintenance of a procedural one. :-P
  • So what should we do instead?
  • I think this is a really sensible resolution :-)
  • ... you got the point ;-) Let’s try to be a little more constructive
  • For example, Mr. Eric Evans has something really interesting to say about how should we implement a Domain Model:
  • What does it mean to “put behaviour in the domain model”? Here is our starting point: all the logic is in the service class.
  • In a “Rich” Domain Model (I really don’t know why is Rich vs Anaemic, maybe “bloody domain model” or “poor domain model” weren’t ok for the job) le logic is “where it belongs” according to Single Responsibility Principle (Martin) or Information Expert (Larman). It’s not spread equally... Customer doesn’t do much, while Money for example looks like a pure data type, but has a lot of math-related behaviour in it.
  • Interestingly, TDD and DDD form a perfect match: DDD needs TDD for many of the key practices, while TDD naturally enforces DDD-like coding styles. It’s just perfect.
  • The next key DDD building block is Aggregates. The Domain Model isn’t flat. Some links are stronger than others (and UML doesn’t really help much in rendering it). If we start considering consistency and behaviour as the primary drivers for modeling our domain we’ll end up with something quite different from a 1-1 projection of the data model.
  • For example, in this case we’ll notice some duplication, related to customer. But lifecycles of the customer and of the order are different. If a customer moves, we don’t want to have all of our past orders changed, at the same time if an order needs to be canceled, we don’t want the user to get down the sink as well. A little duplication is what allows aggregate lifecycles to be independent.
  • Some data-driven analyst are probably really good in spotting these problems just out of their experience.
  • But really, this part of modeling is our everyday work, and should be easy as walking back home in a sunny day.
  • Shouldn’t really have to rely on the experience of some rarely available guy that knows all the traps and hidden perils of data modeling.
  • But here’s something to think about: this modeling style enforces loose coupling between aggregates. As a side effect, queries tend to be a lot simpler and focused. In many situations, this opens the door for some alternative persistence strategy.
  • Ok, so let’s see how DDD can improve our application architecture.
  • Not so many things are happening at the service layer, just basic coordination. Bounded contexts are enforced, and aggregate boundaries within them. But other portions of the architecture don’t change that much. ... is there anything else that we can do?
  • Using DO in the UI seemed like a good idea (I confess I hated the abuse of DTOs so much that I tried it myself), but then you run into objects which are potentially inconsistent. A common solution is to have every DO in 2 possible states: valid and invalid, and valid state must be enforced before any business method is invoked on the object. So why not make it mandatory, with aspects or template method pattern. Why not make this solution available/mandatory to all the domain classes? ... well ...No.
  • Ok, question for the audience: two Stories, hitting different portions of the application, triggered by the same external event. How would you model them? I must admit that in a similar situation I spent some time wondering: “Is it better to have order.purchase(customer, ...) or customer.purchase(order, ...)?” or many other variation on the theme.
  • That’s the very specific Greg Young’s definition. I like it.
  • Domain Events as a communication means between aggregates really simplify things a lot, even at the conceptual level. - Do they really belong to the same transaction? - Would you want the order to roll-bak if you are unable to process the discount for the next order bu the same customer? ... but really, how the two things should be related, is a business choice! We just have more and more possibilites in our arsenal.
  • There’s been a never ending debate in the SOA community (and many dollars and euros wasted) about “service granularity”. A good read of the blue book could have helped a lot, the solution was already there...
  • Let’s start to bite something bigger
  • Which one is the right shoe for you? Well ...it depends :-) each one serves a particular use. We change shoes according to what we want to do.
  • So why should we have only one architecture?
  • CQS existed before DDD and was part of the DDD toolkit collection, basically at the class design level. It really enhances scalability and maintainability.
  • But CQRS promotes the same concept at the architectural level. Commands and quesries have different needs.
  • When we ask, there is generally no behavior involved. Just data.
  • So one first step might be to evolve the “classical” DDD architecture...
  • ... into something more specialized: the domain model is used only in the command side, while the query side is definitely thinner.
  • Let’s dive into the query side. Udi Dahan pointed out that sometimes the biggest source of optimization is to have a look at what the users are really doing: capturing user intent might surprise you.
  • Also, the fact that we can sometimes provide real time data, doesn’t really mean that we must alway provide them. Most of the time a little of delay is absolutely acceptable. Sometimes requirements are not even coming from the business, it’s just IT people showing off...
  • Wow, that is a kind of shock for DDD zealots. Objects are there for the behavior. The domain model is an efficient way to represent behavior. If there’s no behavior then there’s no real need for objects as well. Did I mention that we could get rid of some of our assumptions? ;-)
  • How would you optimize a Query Only architecture? - we could just use some of the tools vendor provide us to manage straight data. - we could have a specialized model for the view, with different table structure, eventually updated by a background process. - ... and many other cool ideas!
  • Also, even stale data could be a great help in managing pleliminary validation of the commands. We can still perform validation on the presentation layer and make sure that most of the commands simply won’t fail .
  • Let’s see the consequences on the command side. More trust means less burden, and a little less synchronicity, meaning less load.
  • Commands are a lot closer to user intent. It’s not just editing data. Is ding it with a purpose.
  • ... so why should show entities in the presentation layer?
  • The domain model turns out to become even simpler: it’s write only. Classes are always in a consistent state and a command issued to the class, triggers an action and/or a state transition. Just that.
  • Let’s get back to the gorilla... what do we need to persist? and How? What’s the most efficient strategy for persisting a domain model?
  • Let’s shake things a little bit more :-)
  • The next little revolution is to have 2 different persistence storage: one optimized fopr working with the domain model? the other one optimized for the Query Only model. The two are eventually consistent. Just think about how many locking issues are blown away by separating the two...
  • Objects are tiny now. No collections, no mapping. Intersting things might happen...
  • Surprisingly, but Udi Dahan and Greg Young in their speeches at last DDDx put the paper-based system at the center of their concern. If a complex system could work without computers ...there must be a reason for that. Some times computers just loeded the systems with more unnecessary complexity.
  • Let’s now face another assumption...
  • You might also want to have a look to Alistair Cockburn exagonal architecture, you might find quite a few similarities in the problem setting.
  • There might be inconsistencies in the data or between the data and the paper. In many system (especially those data-entry based) the paper used to be the Single Source of Truth, but larger integrated systems Events are probably a better candidate.
  • So Events are passing from the command side to the Query side in a publish-subscribe fashion, they need to ba made persistent as well
  • In such a model, what’s the best way to model an entity? Our aggregates are receiveng entities and updating state, can we achieve the same result with a more efficient strategy?
  • The Specification pattern turns out really useful for that, but also note that entities are a little less mutable than they used to be.
  • This might be a blast! Think about the amount of opportunities
  • Ok, this one is a picture I really like, and reuse over and over... DDD has a lot to do with learning. But Event sourcing is a learning tool as well! Only, stop assuming that Business People know everything about the business, there’s a lot more to learn for them also! Why not doing it together?
  • Surprisingly, googling “land of opportunity” leads to Arkansas. But I like this picture... :-)
  • One important lesson: you don’t need all of this at once. But every little step brings an improvement, and it’s worth taking.
  • despite how cool this stuff looks ...be pragmatic.
  • Ok, time for some useful link
  • Loosely Coupled Complexity - Unleash the power of your domain model

    1. 1. Loosely Coupled Complexity <ul><li>Unleash the power of your Domain Model using CQRS & Event Sourcing </li></ul>[email_address]
    2. 2. About me <ul><li>In the IT field since ZX Spectrum </li></ul><ul><li>Generally in large scale projects (I might be biased ) </li></ul><ul><li>Freelance consultant: NotOnlyCode </li></ul><ul><li>Trainer (Freelance & Skills Matter + Zenika) </li></ul><ul><li>Technical Writer </li></ul><ul><li>Blogger: http://ziobrando.blogspot.com </li></ul><ul><li>Twitter: ziobrando </li></ul>My e-mail: [email_address]
    3. 3. <ul><li>@avanscoperta </li></ul><ul><li>www.avanscoperta.it </li></ul><ul><li>avanscoperta.wordpress.com </li></ul><ul><li>[email_address] </li></ul>
    4. 4. Questi 3 tipi hanno qualcosa di veramente interessante da dire...
    5. 5. Cosa c’è che non va? UI Remote facade Application Services DTO DTO ORM
    6. 6. niente
    7. 7. Thank you <ul><li>[email_address] </li></ul><ul><li>http://ziobrando.blogspot.com </li></ul><ul><li>twitter: ziobrando </li></ul>
    8. 8. - Quale gobba?
    9. 9. Quante assunzioni stanno guidando le nostre decisioni?
    10. 10. Proviamo ancora... UI Remote facade Application Services DTO DTO ORM
    11. 11. <ul><li>Anaemic Domain Model </li></ul><ul><li>i DTO? </li></ul><ul><li>Ottimizzazione query su ORM </li></ul><ul><li>Tempo di sviluppo </li></ul><ul><li>Testabilità </li></ul><ul><li>... </li></ul>
    12. 12. <ul><li>Abbiamo veramente bisogno di... </li></ul><ul><ul><li>un Domain Model? </li></ul></ul><ul><ul><li>un Database? </li></ul></ul><ul><ul><li>transazioni? </li></ul></ul><ul><ul><li>un Object Relational Mapper? </li></ul></ul><ul><ul><li>DTO? </li></ul></ul>
    13. 13. Anaemic Domain Model
    14. 14. Non tutti i regali sono necessariamente graditi...
    15. 15. Vantaggi dell’Anaemic Domain Model 1) Il codice business è localizzato in un solo posto: Più facile da leggere per sviluppatori giovani non familiari con OOP. Spiacente ...non c’è il numero 2 :-(
    16. 16. Svantaggi dell’Anemic Domain Model Triste come un pasto in ospedale difficile da matenere difficile da testare alimenta la duplicazione
    17. 17. <ul><li>Progettate la vistra applicazione partendo dal data model </li></ul><ul><li>Create il vostro domain model via reverse engineering </li></ul><ul><li>Dichiarate di fare TDD e cominciate a testare le vostre classi di dominio </li></ul><ul><ul><li>In particolare i getter ed i setters </li></ul></ul><ul><li>Quindi, testate la logica con i test d’Integrazione, ed impantanatevi con i dati di test. </li></ul><ul><li>Dichiarate ufficialmente che TDD non porta alcun vantaggio e che vi fa solo rallentare. </li></ul><ul><li>Commentate i tests nel vostro script di Build - Continuous Integration </li></ul><ul><li>Continuate a lamentarvi </li></ul>Come farsi del male da soli
    18. 18. <ul><li>Non farò più il reverse engineering del data model per creare un domain model </li></ul>
    19. 19. <ul><li>Non farò più il reverse engineering del data model per creare un domain model </li></ul><ul><li>Non farò più il reverse engineering del data model per creare un domain model </li></ul>
    20. 20. <ul><li>Non farò più il reverse engineering del data model per creare un domain model </li></ul><ul><li>Non farò più il reverse engineering del data model per creare un domain model </li></ul><ul><li>Non farò più il reverse engineering del data model per creare un domain model </li></ul>
    21. 21. <ul><li>Non farò più il reverse engineering del data model per creare un domain model </li></ul><ul><li>Non farò più il reverse engineering del data model per creare un domain model </li></ul><ul><li>Non farò più il reverse engineering del data model per creare un domain model </li></ul><ul><li>Non farò più il reverse engineering del data model per creare un domain model </li></ul>
    22. 22. <ul><li>Non farò più il reverse engineering del data model per creare un domain model </li></ul><ul><li>Non farò più il reverse engineering del data model per creare un domain model </li></ul><ul><li>Non farò più il reverse engineering del data model per creare un domain model </li></ul><ul><li>Non farò più il reverse engineering del data model per creare un domain model </li></ul><ul><li>Non farò più il reverse engineering del data model per creare un domain model </li></ul>
    23. 23. <ul><li>Non farò più il reverse engineering del data model per creare un domain model </li></ul><ul><li>Non farò più il reverse engineering del data model per creare un domain model </li></ul><ul><li>Non farò più il reverse engineering del data model per creare un domain model </li></ul><ul><li>Non farò più il reverse engineering del data model per creare un domain model </li></ul><ul><li>Non farò più il reverse engineering del data model per creare un domain model </li></ul><ul><li>Non farò più il reverse engineering del data model per creare un domain model </li></ul>
    24. 24. Come dovremmo implementare un Domain Model? Fate in modo che il codice parli lo Ubiquitous Language Proteggete il vostro modello con dei Bounded Contexts Usate gli Aggregati come unità di consistenza nel vostro domain model Il comportamento dovrebbe risiedere nel Domain Model
    25. 25. Anemic Domain Model
    26. 26. Rich domain model
    27. 27. TDD e DDD Riscritture frequenti Exploratory coding Domain Objects minimali Focus sugli Unit Tests Tiny Domain Objects Tiny Domain Objects Cicli corti e frequenti Codice autoesplicativo Feedback rapido Libertà di cambiare
    28. 28. Aggregate Un gruppo di oggetti naturalmente vicini Unità di consistenza nel domain model modificati nella stessa transazione cancellati insieme trasferiti insieme
    29. 29. Aggregati multipli
    30. 30. Ma la duplicazione non era il male? <ul><li>Se pensiamo ai “dati” allora ...c’è duplicazione </li></ul><ul><li>Se pensiamo al “comportamento” allora alcuni oggetti non sono la stessa cosa </li></ul><ul><li>stabilire i confini degli aggregati rende il nostro sistema </li></ul><ul><ul><li>strettamente consistente all’interno degli aggregate boundaries </li></ul></ul><ul><ul><li>eventualmente consistente al di fuori dei confini dell’aggregato </li></ul></ul>
    31. 31. Alla fine è piuttosto semplice
    32. 32. Perchè complicarsi la vita?
    33. 33. Hmm... Una volta che l’accoppiamento tra gli aggregati è ridotto... potrei anche pensare di scegliere una strategia di persistenza differente per ogni aggregato...
    34. 34. dalla cara vecchia architettura... UI Remote facade Application Services DTO DTO ORM
    35. 35. La visione DDD classica UI Remote facade Application Services DTO DTO ORM bounded contexts aggregate boundaries thin application layer
    36. 36. Portiamo i Domain Objects alla UI? <ul><li>I DTO non piacciono a nessuno... </li></ul><ul><li>Alcuni tool lo permettono! (hey, c’è una camicia hawaiana in regalo!!) </li></ul><ul><li>Il delirio della validazione </li></ul><ul><li>Gli oggetti a 2 stati </li></ul><ul><ul><li>la tentazione del Framework </li></ul></ul>
    37. 37. Come implementereste queste? As a Marketing Office I want to assign discount points to customer on every purchase In order to enable more deals in the future As a Sales Office I want to ship order on purchase command In order to deliver purchased goods to the customer
    38. 38. Eventi e coordinamento fra aggregati <ul><li>Operazione che coinvolgono più aggregati non dovrebbero essere nella stessa Unit of Work </li></ul><ul><li>La comunicazione fra aggregati è intrisecamente asincrona </li></ul><ul><li>Domain Events come meccanismo di comunicazione </li></ul><ul><ul><li>dall’esterno </li></ul></ul><ul><ul><li>fra aggregati </li></ul></ul>
    39. 39. Domain Event <ul><li>nello Ubiquitous Language , sono Azioni Completate : verbi al passato. </li></ul>
    40. 40. Rispondere asincronamente agli eventi <ul><li>Non dimentichiamo: il legame vero tra le azioni è definito dal business!!! </li></ul>
    41. 41. a qualcuno ricorda SOA ? ...proviamo a disegnare le cose diversamente e pensare alla “granularità dei servizi” ...proviamo a disegnare le cose diversamente e pensare alla “granularità dei servizi”
    42. 42. Command/Query Responsibility Segregation Segregation
    43. 44. perché trovare un compromesso ?
    44. 45. Partendo dal piccolo... <ul><li>Command/Query Separation era un principio OOD incluso in DDD </li></ul><ul><ul><li>accessors non dovrebbero avere side effects </li></ul></ul><ul><ul><li>mutators non dovrebbero ritornare un valore </li></ul></ul><ul><ul><ul><li>(con ll’eccezione di this in alcuni casi) </li></ul></ul></ul>
    45. 46. ! Di solito indirizzati ad entità singole il comportamento è importante la Flessibilità è importante Command
    46. 47. ? Grosse quantità di dati Non c’è comportamento le Prestazioni sono importanti Disponibili numerosi componenti off-the shelf Query
    47. 48. da questo... UI Remote facade Application Services DTO DTO ORM
    48. 49. ...a questo UI Remote facade Application Services ORM Remote facade Thin Read Layer DTO DTO
    49. 50. Un percorso separato per comandi inviati al Domain Model Un percorso separato per recuperare Dati
    50. 51. Querying <ul><li>Date un’occhiata ai vostri utenti , cosa interessa loro veramente? </li></ul><ul><ul><li>Non è cercare, è trovare </li></ul></ul><ul><ul><li>Non è il refresh , stanno cercando eventi </li></ul></ul>
    51. 52. Staleness <ul><li>È veramente un problema ? </li></ul><ul><li>Importa veramente se i dati sono... </li></ul><ul><ul><li>di 20 secondi fa? </li></ul></ul><ul><ul><li>O di 10 minuti ? </li></ul></ul><ul><li>... chi siamo noi per decidere questa cosa? </li></ul><ul><li>... puoi tenere sincronizzata una stampa ? </li></ul><ul><ul><li>o un PowerPoint ? </li></ul></ul>
    52. 53. Sono solo dati <ul><li>Non c’è comportamento in quello che vediamo. </li></ul><ul><li>Abbiamo veramente bisogno di oggetti ? </li></ul>
    53. 54. Query-Only Architecture <ul><li>Sono solo dati: no comportamento... </li></ul><ul><ul><li>=> perché non andare dritti sul database ? </li></ul></ul><ul><li>Non c’è accoppiamento tra le schermate della UI... </li></ul><ul><ul><li>=> Abbiamo veramente bisogno della referential integrity? </li></ul></ul><ul><ul><li>=> Perché non usare una table-per-UI-view strategy, calcolata in background? </li></ul></ul><ul><li>Cosa stiamo già facendo con il search model e con la cache ? </li></ul>
    54. 55. Anche i dati stale possono <ul><li>... fornire informazioni utili per la validazione preliminare dei comandi </li></ul><ul><ul><li>=> meno comandi che falliscono </li></ul></ul>
    55. 56. ...meno comandi che falliscono <ul><li>Se la maggio parte dei nostri comandi avrà successo... </li></ul><ul><li>... c’è veramente bisogno di rispondere immediatamente o sullo stesso canale ? </li></ul><ul><li>Perché non qualcosa come: “ Thank you for your order, your confirmation e-mail will arrive shortly ”? </li></ul>
    56. 57. Catturare le intenzioni dell’utente <ul><li>Sappiamo realmente cosa l’utente vuole fare con la nostra applicazione ? </li></ul><ul><li>Stiamo realmente supportando i nostri utenti? </li></ul><ul><li>Chi si sta facendo carico della complessità? </li></ul><ul><li>... non possiamo fare qualcosa di più intelligente che semplicemente mostrare dati grezzi ? </li></ul><ul><ul><li>...un sacco di carico sul versante dati è sostanzialmente inutile </li></ul></ul>
    57. 58. Commands != Entities <ul><li>Non c’è molto in comune... </li></ul><ul><ul><li>per quale motivo devo mostrarle all’utente? </li></ul></ul>
    58. 59. Write-only model <ul><li>Il domain model non è usato per recuperare o mostrare dati. </li></ul><ul><ul><li>Le relazioni tra entità orientate al recupero dei dati ... non sono più necessarie </li></ul></ul><ul><li>Il Domain Model è sempre in uno stato consistente (dalla Factory alla Garbage Collection) </li></ul><ul><li>Non è necessaria la validazione sul Domain Model (comandi sono validati prima ) </li></ul><ul><li>Testare il Domain Model diventa ancora più semplice </li></ul>
    59. 60. Persisting the model <ul><li>Abbiamo veramente bisogno di rendere persistenti tutti i dati ? </li></ul><ul><li>Abbiamo veramente bisogno di renderli persistenti su un supporto Relazionale ? </li></ul><ul><ul><li>(ricordate, non stiamo facendo query sul modello...) </li></ul></ul>
    60. 61. UI Remote facade Application Services ORM Remote facade Thin Read Layer DTO Commands
    61. 62. voilà UI Remote facade Application Services ORM? Remote facade Thin Read Layer DTO publish subscribe Specialized data model does it really need to be relational? Commands Eventually
    62. 63. un interessante side effect <ul><li>... meno collections ... </li></ul><ul><li>=> meno impatto sulla memoria </li></ul><ul><li>=> meno Garbage Collection </li></ul><ul><li>su alcuni sistemi, il Domain Model è sempre disponibile </li></ul>
    63. 64. The paper-based system Molti tipi di azienda nascono prima dei computers Le transazioni non sono un problema bisiness I Dati possono essere disallineati...capita CHIEDIAMO al Business
    64. 65. Event Sourcing
    65. 66. Quindi ...cosa fa il nostro Domain Model? <ul><li>fondamentalmente risponde a messaggi autocontenuti provenienti dall’esterno... </li></ul><ul><ul><li>eventi dalla UI o da sorgenti esterne </li></ul></ul>
    66. 67. La singola sorgente di verità <ul><li>Un tempo era la carta ... </li></ul><ul><li>ora sono gli Eventi </li></ul>
    67. 68. voilà UI Remote facade Application Services ORM ? Remote facade Thin Read Layer DTO publish subscribe Events Events
    68. 69. Dobbiamo tenere lo stato nelle Entities? <ul><li>Abbiamo tutte le informazioni necessarie nella Event Queue </li></ul><ul><ul><li>SINGLE SOURCE of TRUTH </li></ul></ul><ul><li>Cos’è un Aggregato? qualcosa che cambia il suo stato in risposta ad eventi </li></ul><ul><ul><li>...secondo il nostro livello attuale di comprensione del sistema </li></ul></ul>
    69. 70. Aggregati ed eventi <ul><li>Gli aggregati tengono traccia degli eventi e derivano il proprio comportamento di conseguenza </li></ul>
    70. 71. Che succede se... <ul><li>deriviamo lo stato degli Aggregati dalla sequenza degli eventi che sono avvenuti in un sistema? </li></ul><ul><li>=> Possiamo avere feaures retroattive ... </li></ul><ul><li>=> Possiamo rispondere SI ad un sacco di richieste strane/interessanti che arrivano dal business. </li></ul><ul><li>=> Riprodurre bug ? </li></ul>
    71. 73. Gli aggregati disaccoppiati permettono semplificazioni nello sviluppo La terra delle opportunità Polyglot persistence migliore scalabilità Polyglot persistence Polyglot persistence Polyglot persistence SOA indolore Applicazioni riavvolgibili
    72. 74. Una cosa alla volta Non è detto che abbiate bisogno di tutto Ogni step è un miglioramento Anche in piccole architetture ...Mettiamo in discussione un’assunzione alla volta ...Mettiamo in discussione un’assunzione alla volta ...Mettiamo in discussione un’assunzione alla volta ...Mettiamo in discussione un’assunzione alla volta ...Mettiamo in discussione un’assunzione alla volta
    73. 77. References <ul><li>http://groups.google.com/group/dddcqrs </li></ul><ul><li>http://cqrs.wordpress.com/ </li></ul><ul><li>http://www.infoq.com/interviews/Architecture-Eric-Evans-Interviews-Greg-Young </li></ul><ul><li>http://www.udidahan.com/2009/12/09/clarified-cqrs/ </li></ul><ul><li>http://www.infoq.com/presentations/Command-Query-Responsibility-Segregation </li></ul><ul><li>http://www.infoq.com/presentations/SOA-Business-Autonomous-Components </li></ul><ul><li>http://martinfowler.com/eaaDev/EventSourcing.html </li></ul><ul><li>http://skillsmatter.com/podcast/design-architecture/architectural-innovation-eventing-event-sourcing </li></ul>
    74. 78. Thank you <ul><li>[email_address] </li></ul><ul><li>http://ziobrando.blogspot.com </li></ul><ul><li>twitter: ziobrando </li></ul>

    ×