DDD IN A DISTRIBUTED WORLD

703 views
559 views

Published on

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

  • Be the first to like this

No Downloads
Views
Total views
703
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
12
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

DDD IN A DISTRIBUTED WORLD

  1. 1. DDD IN A DISTRIBUTED WORLD Gojko Adzic http://gojko.net gojko@gojko.net @gojkoadzic
  2. 2. Aggregates... Object clusters defining strong relationships… ...objects outside of an aggregate should only reference the aggregate root and not anything inside it.
  3. 3. Aggregates are not just about pointers
  4. 4. Aggregates are not just about pointers Think of business units of consistency
  5. 5. Aggregates are not just about pointers Think of business units of consistency “a meaningful whole”
  6. 6. Technical impacts  A natural unit of distribution
  7. 7. Technical impacts  A natural unit of distribution  A natural unit for transactions
  8. 8. Technical impacts  A natural unit of distribution  A natural unit for transactions  A natural unit of synchronous work
  9. 9. Hint #1: If you don't aggregate enough,even the fastest computers will spin their wheels in vain http://www.flickr.com/photos/cianginty/
  10. 10. Latency
  11. 11. Aggregate is a meaningful whole... So whoever needs a part of it probably needs it whole
  12. 12. Ship entire aggregates straight away to avoid latency
  13. 13. Hint #2: If you aggregate too much, baggage becomes a problem http://www.flickr.com/photos/12496504@N06
  14. 14. What is the boundary here?
  15. 15. If you don't need it all, it is probably not an aggregate
  16. 16. Hint #3: If you don't aggregate enough, things are going to be broken just when you need them http://www.flickr.com/photos/nowhere77 /
  17. 17. Aggregates are units of consistency... so aggregate updates should obey the samurai principle: Either return successfully or not at all
  18. 18. An aggregate should be processed synchronously within a transaction
  19. 19. Hint #4: If you aggregate wrong things, deadlocks galore http://www.flickr.com/photos/meckleychina /
  20. 20. What should we lock here?
  21. 21. When we lock, we should really lock aggregates
  22. 22. The technical and the business side of aggregates confirm and reinforce each-other
  23. 23. Spotting conflicts between them points to problems straight away! Unless these are resolved, the system is just not going to work
  24. 24. Summary  Aggregates are a business concept – a unit of consistency and a meaningful whole  Technically they are units of distribution, locking and synchronicity  A conflict between the two sides points to design issues  Getting them just right is a key to making a nicely designed and performant system
  25. 25. gojko@gojko.com http://gojko.net @gojkoadzic

×