Your SlideShare is downloading. ×
DDD IN A DISTRIBUTED WORLD
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

DDD IN A DISTRIBUTED WORLD

481
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
481
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
12
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. DDD IN A DISTRIBUTED WORLD Gojko Adzic http://gojko.net gojko@gojko.net @gojkoadzic
  • 2. Aggregates... Object clusters defining strong relationships… ...objects outside of an aggregate should only reference the aggregate root and not anything inside it.
  • 3. Aggregates are not just about pointers
  • 4. Aggregates are not just about pointers Think of business units of consistency
  • 5. Aggregates are not just about pointers Think of business units of consistency “a meaningful whole”
  • 6. Technical impacts  A natural unit of distribution
  • 7. Technical impacts  A natural unit of distribution  A natural unit for transactions
  • 8. Technical impacts  A natural unit of distribution  A natural unit for transactions  A natural unit of synchronous work
  • 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. Latency
  • 11. Aggregate is a meaningful whole... So whoever needs a part of it probably needs it whole
  • 12. Ship entire aggregates straight away to avoid latency
  • 13. Hint #2: If you aggregate too much, baggage becomes a problem http://www.flickr.com/photos/12496504@N06
  • 14. What is the boundary here?
  • 15. If you don't need it all, it is probably not an aggregate
  • 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. Aggregates are units of consistency... so aggregate updates should obey the samurai principle: Either return successfully or not at all
  • 18. An aggregate should be processed synchronously within a transaction
  • 19. Hint #4: If you aggregate wrong things, deadlocks galore http://www.flickr.com/photos/meckleychina /
  • 20. What should we lock here?
  • 21. When we lock, we should really lock aggregates
  • 22. The technical and the business side of aggregates confirm and reinforce each-other
  • 23. Spotting conflicts between them points to problems straight away! Unless these are resolved, the system is just not going to work
  • 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. gojko@gojko.com http://gojko.net @gojkoadzic