Your SlideShare is downloading. ×
0
<ul>Command your Domain </ul><ul>Lourens Naude, WildfireApp.com </ul>
<ul>Background </ul><ul><li>Independent Contractor </li></ul><ul><ul><li>Ruby / C / integrations
Well versed full stack
Architecture </li></ul></ul><ul><li>WildfireApp.com </li></ul><ul><ul><li>Social Marketing platform
Large whitelabel clients
Bursty traffic – Lady Gaga, EA, Gatorade </li></ul></ul>
 
<ul>Audience </ul><ul><li>Monolithic applications </li></ul><ul><ul><li>Scale together, fail together
Often have an anemic domain model, scattered logic
Hockey stick function – fast initial growth, increasingly difficult to extend over time
Hacks always have the longest lifecycle in a codebase </li></ul></ul><ul><li>Target platforms </li></ul><ul><ul><li>Projec...
Existing monolithic applications
Environments with excessive coupling or dependencies </li></ul></ul>
<ul>MAINTENANCE COST IS MULTIPLE TIMES MORE THAN DEVELOPMENT COST </ul>
<ul>Anemic Domain Models </ul><ul><li>Cost to business </li></ul><ul><ul><li>No competitive advantage
Long dev -> production cycle </li></ul></ul><ul><li>Identified by ... </li></ul><ul><ul><li>Tech oriented interfaces
High coupling to neighboring layers
Coupled persistence
Dependencies on host frameworks </li></ul></ul>
<ul>Layered Architecture </ul><ul><li>Layers </li></ul><ul><ul><li>UI
Application
Domain
Infrastructure </li></ul></ul><ul><li>Rails && other MVC ? </li></ul><ul><ul><li>All of the above, monolithic tree
Modeling is often data driven, not behavior driven
Models / entities are often coupled to conventions and dependencies of the host framework </li></ul></ul>
<ul>Problems in practice </ul><ul><li>Rails as a niche framework </li></ul><ul><ul><li>Initial conventions scale for small...
Fast time to market
Request / response + rendering
Beyond this, generally not a Rails application anymore </li></ul></ul><ul><li>Development and growth </li></ul><ul><ul><li...
Conventions, practices and dependencies should grow with and adapt to that also  </li></ul></ul>
<ul>APPLICATIONS AS A FRAMEWORK </ul>
<ul>Custom policies and governance </ul><ul><li>Cater for both developers + production runtime </li></ul><ul><ul><li>Envir...
Configuration management
Dependency management etc. </li></ul></ul><ul><li>How ? </li></ul><ul><ul><li>Thin framework agnostic layer that provides ...
Piggyback off known contracts eg. cache['something']
Deprecate framework specific references in code
Prefer SomeApp.cache to Rails.cache etc. </li></ul></ul>
<ul>Moving off monilithic apps </ul><ul><li>How features used to roll out </li></ul><ul><ul><li>Slapped onto the existing ...
Spawned a new project, with yet another set of conventions
Topic / feature development branches </li></ul></ul><ul><li>Challenges </li></ul><ul><ul><li>Team likely not structured to...
Extreme self-discipline, from everyone
Business Process Model skills is required </li></ul></ul>
<ul>DOMAIN MODELLING PRIMER </ul>
<ul>Digesting a domain </ul><ul><li>Language </li></ul><ul><ul><li>Ban  acronyms
Push for a common language – dev, product + biz
Be childlike.Why, why, why ... </li></ul></ul><ul><li>Open ended </li></ul><ul><ul><li>A domain representation is always i...
It'll be enhanced with new concepts
Weed out vague / deprecated elements
Refactorings at this level is often overlooked </li></ul></ul>
<ul>Refactoring strategies </ul><ul><li>Continuously throw usage scenarios at your system
Refactor to deeper insights
Extract hidden concepts – look for edge cases, policies etc.
In cooperation with domain experts
Refactor your domain first, code second </li></ul>
<ul>Behavior and responsibility </ul><ul><li>Ignore schema and attributes </li></ul><ul><ul><li>Should not be the core of ...
Assigning data to entities prior to knowing that they do ? </li></ul></ul><ul><li>Behavior </li></ul><ul><ul><li>Partition...
Distribute responsibilities first
Then decide what each entity needs to know </li></ul></ul>
<ul>DOMAIN FRAGMENTATION </ul>
<ul>Domain leaks - People </ul><ul><li>Developers </li></ul><ul><ul><li>Code ownership
Some developers don't communicate well
Snapshot thoughts to wiki != fun
People come, people go </li></ul></ul><ul><li>Product and business </li></ul><ul><ul><li>Not willing to get into domain de...
Concerned with features
Concerned with cash flow </li></ul></ul>
<ul>Domain leaks – Process </ul><ul><li>Reorganization </li></ul><ul><ul><li>Migrates knowledge excessively
Fine balance between code ownership and moving developers around too much </li></ul></ul><ul><li>Practices and culture </l...
Upcoming SlideShare
Loading in...5
×

RailswayCon 2010 - Command Your Domain

3,646

Published on

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

No Downloads
Views
Total Views
3,646
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
73
Comments
0
Likes
5
Embeds 0
No embeds

No notes for slide

Transcript of "RailswayCon 2010 - Command Your Domain"

  1. 1. <ul>Command your Domain </ul><ul>Lourens Naude, WildfireApp.com </ul>
  2. 2. <ul>Background </ul><ul><li>Independent Contractor </li></ul><ul><ul><li>Ruby / C / integrations
  3. 3. Well versed full stack
  4. 4. Architecture </li></ul></ul><ul><li>WildfireApp.com </li></ul><ul><ul><li>Social Marketing platform
  5. 5. Large whitelabel clients
  6. 6. Bursty traffic – Lady Gaga, EA, Gatorade </li></ul></ul>
  7. 8. <ul>Audience </ul><ul><li>Monolithic applications </li></ul><ul><ul><li>Scale together, fail together
  8. 9. Often have an anemic domain model, scattered logic
  9. 10. Hockey stick function – fast initial growth, increasingly difficult to extend over time
  10. 11. Hacks always have the longest lifecycle in a codebase </li></ul></ul><ul><li>Target platforms </li></ul><ul><ul><li>Projects with significant complexity
  11. 12. Existing monolithic applications
  12. 13. Environments with excessive coupling or dependencies </li></ul></ul>
  13. 14. <ul>MAINTENANCE COST IS MULTIPLE TIMES MORE THAN DEVELOPMENT COST </ul>
  14. 15. <ul>Anemic Domain Models </ul><ul><li>Cost to business </li></ul><ul><ul><li>No competitive advantage
  15. 16. Long dev -> production cycle </li></ul></ul><ul><li>Identified by ... </li></ul><ul><ul><li>Tech oriented interfaces
  16. 17. High coupling to neighboring layers
  17. 18. Coupled persistence
  18. 19. Dependencies on host frameworks </li></ul></ul>
  19. 20. <ul>Layered Architecture </ul><ul><li>Layers </li></ul><ul><ul><li>UI
  20. 21. Application
  21. 22. Domain
  22. 23. Infrastructure </li></ul></ul><ul><li>Rails && other MVC ? </li></ul><ul><ul><li>All of the above, monolithic tree
  23. 24. Modeling is often data driven, not behavior driven
  24. 25. Models / entities are often coupled to conventions and dependencies of the host framework </li></ul></ul>
  25. 26. <ul>Problems in practice </ul><ul><li>Rails as a niche framework </li></ul><ul><ul><li>Initial conventions scale for small to medium size applications
  26. 27. Fast time to market
  27. 28. Request / response + rendering
  28. 29. Beyond this, generally not a Rails application anymore </li></ul></ul><ul><li>Development and growth </li></ul><ul><ul><li>Your application, over time, becomes your framework for future development
  29. 30. Conventions, practices and dependencies should grow with and adapt to that also </li></ul></ul>
  30. 31. <ul>APPLICATIONS AS A FRAMEWORK </ul>
  31. 32. <ul>Custom policies and governance </ul><ul><li>Cater for both developers + production runtime </li></ul><ul><ul><li>Environment support with sanity checks
  32. 33. Configuration management
  33. 34. Dependency management etc. </li></ul></ul><ul><li>How ? </li></ul><ul><ul><li>Thin framework agnostic layer that provides tooling for developers
  34. 35. Piggyback off known contracts eg. cache['something']
  35. 36. Deprecate framework specific references in code
  36. 37. Prefer SomeApp.cache to Rails.cache etc. </li></ul></ul>
  37. 38. <ul>Moving off monilithic apps </ul><ul><li>How features used to roll out </li></ul><ul><ul><li>Slapped onto the existing codebase OR
  38. 39. Spawned a new project, with yet another set of conventions
  39. 40. Topic / feature development branches </li></ul></ul><ul><li>Challenges </li></ul><ul><ul><li>Team likely not structured to support distributed / decoupled systems
  40. 41. Extreme self-discipline, from everyone
  41. 42. Business Process Model skills is required </li></ul></ul>
  42. 43. <ul>DOMAIN MODELLING PRIMER </ul>
  43. 44. <ul>Digesting a domain </ul><ul><li>Language </li></ul><ul><ul><li>Ban acronyms
  44. 45. Push for a common language – dev, product + biz
  45. 46. Be childlike.Why, why, why ... </li></ul></ul><ul><li>Open ended </li></ul><ul><ul><li>A domain representation is always in flux during development, especially if it's new to developers
  46. 47. It'll be enhanced with new concepts
  47. 48. Weed out vague / deprecated elements
  48. 49. Refactorings at this level is often overlooked </li></ul></ul>
  49. 50. <ul>Refactoring strategies </ul><ul><li>Continuously throw usage scenarios at your system
  50. 51. Refactor to deeper insights
  51. 52. Extract hidden concepts – look for edge cases, policies etc.
  52. 53. In cooperation with domain experts
  53. 54. Refactor your domain first, code second </li></ul>
  54. 55. <ul>Behavior and responsibility </ul><ul><li>Ignore schema and attributes </li></ul><ul><ul><li>Should not be the core of your design process
  55. 56. Assigning data to entities prior to knowing that they do ? </li></ul></ul><ul><li>Behavior </li></ul><ul><ul><li>Partition objects and entities by behavior
  56. 57. Distribute responsibilities first
  57. 58. Then decide what each entity needs to know </li></ul></ul>
  58. 59. <ul>DOMAIN FRAGMENTATION </ul>
  59. 60. <ul>Domain leaks - People </ul><ul><li>Developers </li></ul><ul><ul><li>Code ownership
  60. 61. Some developers don't communicate well
  61. 62. Snapshot thoughts to wiki != fun
  62. 63. People come, people go </li></ul></ul><ul><li>Product and business </li></ul><ul><ul><li>Not willing to get into domain details
  63. 64. Concerned with features
  64. 65. Concerned with cash flow </li></ul></ul>
  65. 66. <ul>Domain leaks – Process </ul><ul><li>Reorganization </li></ul><ul><ul><li>Migrates knowledge excessively
  66. 67. Fine balance between code ownership and moving developers around too much </li></ul></ul><ul><li>Practices and culture </li></ul><ul><ul><li>Lack of Documentation culture
  67. 68. Not factoring clued up domain experts into projects
  68. 69. Shielding departments from each other – us VS them
  69. 70. Visual communication.Whiteboards ? Diagrams ?
  70. 71. Domain discussions encouraged ? Shot down ? </li></ul></ul>
  71. 72. <ul>Domain leaks - concepts </ul><ul><li>Implicit concepts </li></ul><ul><ul><li>Instrumental in understanding a model
  72. 73. But never referenced in an implementation
  73. 74. Frequently would be hinted at, but may not seem important to pull in </li></ul></ul><ul><li>Explicit concepts </li></ul><ul><ul><li>Merging implicit concepts back into the domain
  74. 75. Over time, this leads to breakthroughs
  75. 76. Less edge cases
  76. 77. Ability to handle offline process programatically </li></ul></ul>
  77. 78. <ul>Notes on errors </ul><ul><li>Common error types </li></ul><ul><ul><li>Runtime errors
  78. 79. Exceptions
  79. 80. Errors in business logic </li></ul></ul><ul><li>Explicit domain errors </li></ul><ul><ul><li>Don't inline raise
  80. 81. Do include business errors in your domain
  81. 82. Define strategies for offline or programatic handling </li></ul></ul>
  82. 83. <ul>STATE OF YOUR DOMAIN </ul>
  83. 84. <ul>Loosely coupled domain </ul>-------------------------------------- X <-- X <-- X <-- X --------------------------------------
  84. 85. <ul>Sparse domain </ul>-------------------------------------- X <-- <-- <-- X --------------------------------------
  85. 86. <ul>Highly coupled domain </ul>-------------------------------------- X X <-- X X <-- X X <-- XXXX --------------------------------------
  86. 87. <ul>COMMUNICATION </ul>
  87. 88. <ul>Value of speech </ul><ul><li>Talking out loud </li></ul><ul><ul><li>Embrace senses
  88. 89. Colorful speech
  89. 90. “ A valid tax invoice for taxable sales that totals x”
  90. 91. Fail faster – quicker feedback loop </li></ul></ul><ul><li>Translation costs </li></ul><ul><ul><li>Statement ...
  91. 92. Refine statement ...
  92. 93. Agree on statement ...
  93. 94. repeat </li></ul></ul>
  94. 95. <ul>A Common Language </ul><ul><li>Participants </li></ul><ul><ul><li>Domain experts
  95. 96. Stakeholders
  96. 97. Developers </li></ul></ul><ul><li>Referenced in </li></ul><ul><ul><li>Code
  97. 98. Test code
  98. 99. Discussions and meetings
  99. 100. Specs / diagrams
  100. 101. Documentation </li></ul></ul>
  101. 102. <ul>Common Language Elements </ul><ul><li>Nouns </li></ul><ul><ul><li>Entities / classes if it has identity
  102. 103. Invoice, transaction, business, user, expense etc.
  103. 104. Value object if there's no identity.Reusable and immutable
  104. 105. Address, Money etc. (load Address via User) </li></ul></ul><ul><li>Verbs </li></ul><ul><ul><li>Services, methods etc. - behavior
  105. 106. “ A transaction between businesses generates an invoice.”
  106. 107. @business.sells(2, product, other_biz) </li></ul></ul>
  107. 108. <ul><li>VERBS AS COMMANDS </li></ul>
  108. 109. <ul><li>EVENT IS THE RESULT OF PROCESSING A COMMAND </li></ul>
  109. 110. <ul>Command -> event stream </ul>Sell(:seller => 'Acme', :quantity => 2, :product => 'XYZ', :buyer => 'MegaCorp') @business.sells(2, product, other_biz) [PaymentProcessed, TransactionCreated, InventoryUpdated, InvoiceCreated, ShippingLabelsGenerated ]
  110. 111. <ul><li>EXPLICIT STATE CHANGES </li></ul>
  111. 112. <ul>Pushing changes </ul><ul><li>Rethink persistence </li></ul><ul><ul><li>Remove persistance behavior from entities
  112. 113. Focus on the domain, not data structure
  113. 114. Delegate storage to a repository
  114. 115. Easy to swap out repository implementations for testing etc. </li></ul></ul><ul><li>Domain events </li></ul><ul><ul><li>Instead of saving to the database, generate a domain event with the relevant changes as a payload
  115. 116. Published to your whole stack
  116. 117. Eventual consistency </li></ul></ul>
  117. 118. <ul>ActiveRecord implications </ul><ul><li>Reporting contexts </li></ul><ul><ul><li>ActiveRecord::Base.read_only!
  118. 119. Bypass persistence entirely – force ready-only mode
  119. 120. @record.attributes #=> value object
  120. 121. @record.changed #=> value object diff </li></ul></ul><ul><li>Repository use cases </li></ul><ul><ul><li>A Generic Repository implementation (CRUD)
  121. 122. Invoice.find(1) #=> entity by identity
  122. 123. Invoice.find_by_refr(x) #=> dynamic and explicit query methods </li></ul></ul>
  123. 124. <ul>EVENTED ARCHITECTURE </ul>
  124. 125. <ul>Commands </ul><ul><li>Drive change in your system </li></ul><ul><ul><li>Time driven : batched, cron etc.
  125. 126. Request / Response : remote producedure calls </li></ul></ul><ul><li>Definition </li></ul><ul><ul><li>A well defined task / behavior with parameters
  126. 127. Not expected to return a result
  127. 128. Should be idempotent
  128. 129. Should expire itself when not processed in a timeframe
  129. 130. Yields an event stream through interaction with the domain when processed instead </li></ul></ul>
  130. 131. <ul>Domain Events </ul><ul><li>Granularity </li></ul><ul><ul><li>InvoiceChanged, InvoiceStateChanged, InvoicePaid
  131. 132. Try to signal the intent of a change
  132. 133. Wrap InvoiceChanged in a module
  133. 134. InvoicePaid.include InvoiceChanged </li></ul></ul><ul><li>Immutability </li></ul><ul><ul><li>Represents something that has happened
  134. 135. Thus properties should never be changed </li></ul></ul>
  135. 136. <ul>Event Driven Architecture (EDA) </ul><ul><li>Nervous system anology – hand on stove </li></ul><ul><ul><li>Hand is the event producer
  136. 137. Spinal cord is the ESB
  137. 138. Brain is the event listener
  138. 139. Brain is the event processor
  139. 140. Hand is the event reaction – we pull away </li></ul></ul><ul><li>Common event patterns </li></ul><ul><ul><li>Generation
  140. 141. Consumption
  141. 142. Processing </li></ul></ul>
  142. 143. <ul>EDA attributes </ul><ul><li>Definition </li></ul><ul><ul><li>Loosely coupled / decoupled
  143. 144. Async messaging
  144. 145. Granular events
  145. 146. Notification of state changes </li></ul></ul><ul><li>Transport </li></ul><ul><ul><li>ESB backbone
  146. 147. No centralized control </li></ul></ul>
  147. 148. <ul>COMMAND AND QUERY SEPERATION </ul>
  148. 149. <ul>EITHER PERFORM AN ACTION OR RETURN A RESULT </ul>
  149. 150. <ul>* NOT BOTH * </ul>
  150. 151. <ul>COMMANDS CHANGE STATE, QUERIES EXAMINE THEM </ul>
  151. 152. <ul>Major differences </ul><ul><li>Queries </li></ul><ul><ul><li>Synchronous and blocking
  152. 153. Idempotent by default </li></ul></ul><ul><li>Commands </li></ul><ul><ul><li>Asyncronous – we expect no results …
  153. 154. Other than a guarantee it's been received
  154. 155. Should be idempotent / not reprocessed </li></ul></ul>
  155. 156. <ul>Read and write seperation </ul><ul><li>Write service </li></ul><ul><ul><li>POST /invoices
  156. 157. PUT /invoice/1
  157. 158. DESTROY /invoice/1
  158. 159. Append to a FIFO command queue </li></ul></ul><ul><li>Read service </li></ul><ul><ul><li>GET /invoice/1
  159. 160. GET /invoices
  160. 161. Serve from an eventually consistent reporting DB </li></ul></ul>
  161. 162. <ul>“ Hot” upgrades </ul><ul><li>Scenario </li></ul><ul><ul><li>Read heavy web application
  162. 163. 95% read, 5% write
  163. 164. System upgrade required
  164. 165. Ability to disable features is explicit in domain </li></ul></ul><ul><li>Solution </li></ul><ul><ul><li>Mirror all data
  165. 166. Disable all write services + related features
  166. 167. Continue serving requests </li></ul></ul>
  167. 168. <ul>CRUD FAIL </ul>
  168. 169. <ul>Why ? </ul><ul><li>Audits
  169. 170. Can't be easily audited </li></ul><ul><ul><li>You can, but pointless if your system isn't dependent on this history – no way to trust it </li></ul></ul><ul><li>Accountant workflow </li></ul><ul><ul><li>Accountants don't change objects
  170. 171. They keep histories
  171. 172. No updates, no deletes
  172. 173. Work is always auditable
  173. 174. Totals is always based on history </li></ul></ul>
  174. 175. <ul>Change oriented updates </ul><ul><li>CRUD API </li></ul><ul><ul><li>Create
  175. 176. UPDATE
  176. 177. Delete
  177. 178. What's changed on UPDATE ? </li></ul></ul><ul><li>A better API </li></ul><ul><ul><li>#rename_invoice
  178. 179. #update_line_item_quantity </li></ul></ul>
  179. 180. <ul>AUDITS AND CONSISTENCY </ul>
  180. 181. <ul>Audit workflow </ul><ul><li>Commands </li></ul><ul><ul><li>Stored in a sequential FIFO fashion
  181. 182. Allows for compensation on multiple updates
  182. 183. Entity state is driven exclusively from this
  183. 184. Guaranteed – as there's no other persistence </li></ul></ul><ul><li>Audit logs </li></ul><ul><ul><li>Command -> Domain -> Domain event
  184. 185. Aggregates domain events
  185. 186. Feeds into a reporting database </li></ul></ul>
  186. 187. <ul>What's really happening here ? </ul><ul><li>Isolated contexts </li></ul><ul><ul><li>Command store
  187. 188. Audit log store
  188. 189. Reporting database
  189. 190. Agree through communication </li></ul></ul><ul><li>Eventual consistency </li></ul><ul><ul><li>We don't guarantee consistenty accross these contexts
  190. 191. at all times
  191. 192. We do guarantee that it'll be consistent eventually
  192. 193. Relaxed consistency is often acceptable </li></ul></ul>
  193. 194. <ul>Relaxed Consistency </ul><ul><li>Viability ? </li></ul><ul><ul><li>Discuss with domain experts
  194. 195. How long is too long ? </li></ul></ul><ul><li>Solutions </li></ul><ul><ul><li>Explicit SLA's at the command level
  195. 196. Measure propogation and flag SLA violations </li></ul></ul>
  196. 197. <ul>PERFORMANCE AND TESTING </ul>
  197. 198. <ul>Performance benefits </ul><ul><li>Throughput </li></ul><ul><ul><li>High transactions/sec rate
  198. 199. Total throughput is always governed by the weakest link </li></ul></ul><ul><li>Read / write specific optimizations </li></ul><ul><ul><li>Latency: data being far from where it's needed
  199. 200. Never block a write on waiting for data – it's given
  200. 201. Can use fast disks for write oriented services
  201. 202. Cache read tier ftw!
  202. 203. Formal state changes == better cache invalidation </li></ul></ul>
  203. 204. <ul>Testing </ul><ul><li>Service / daemon structure </li></ul><ul><ul><li>Command -> Result
  204. 205. Result being either an Event or Error </li></ul></ul><ul><li>Workflow </li></ul><ul><ul><li>test/unit, domain elements + your service
  205. 206. Layered architectured == easy to swap out layers
  206. 207. Arrays to mock queue infrastructure
  207. 208. Behavior driven testing
  208. 209. Assert resulting events or errors </li></ul></ul>
  209. 210. <ul>Asserting events </ul>process MyApp::Payments do command :PayInvoice, :id => 1 assert_events :InvoicePaid, :RegenInvoice end
  210. 211. <ul>Asserting errors </ul>process MyApp::Payments do command :PayInvoice, :id => 200 assert_errors :InvoiceAlreadyPaid end
  211. 212. <ul>Commands in test cases </ul>def command(cmd, attrs) cmd = App::Commands.const_get(cmd).new attrs.each{|k,v| cmd[k] = v } @process << cmd end alias input command
  212. 213. <ul>Asserting event streams </ul>def assert_events(*events) event_types = @output.map{|e| e.class } expected = events.map{|e| App::Events.const_get(e) } assert_equal expected, event_types, &quot;Expected events #{expected.inspect}, got #{event_types.inspect}&quot; end
  213. 214. <ul>MESSAGING </ul>
  214. 215. <ul>Messages - Communication </ul><ul><li>Communication styles </li></ul><ul><ul><li>Fat consumer : service call to determine destination, then send, slow
  215. 216. Thin consumer : fire and forget, ESB routes, fast </li></ul></ul><ul><li>ESB </li></ul><ul><ul><li>Take time to research this
  216. 217. Understand the protocol
  217. 218. Client support
  218. 219. Durability and failover requirements
  219. 220. Publish / subscribe is preferred </li></ul></ul>
  220. 221. <ul>Messages - Types </ul><ul><li>Loose coupling requirements </li></ul><ul><ul><li>Weak typing, loose data model - hashes
  221. 222. Data types not always harmonized – accept that
  222. 223. Also account for foreign / API messages </li></ul></ul><ul><li>Translation support </li></ul><ul><ul><li>Requires mapping between systems
  223. 224. Individual systems can modify their internal structures, providing we update our mapping layer
  224. 225. Useful if we have foreign messages (via API) to push in our stack as well – just coerce to the internal representation </li></ul></ul>
  225. 226. <ul>Messages - Versioning </ul><ul><li>Embracing change </li></ul><ul><ul><li>Structures will change
  226. 227. Version backward incompatible changes
  227. 228. Intermediate sensible defaults for backward compatible changes </li></ul></ul><ul><li>Strategies </li></ul><ul><ul><li>Let queues be a part of version strategy also
  228. 229. Allows for keeping old + new messages – no loss
  229. 230. Thin and temp. translator to pop messages off the old queue, translate / coerce them, push to the new one </li></ul></ul>
  230. 231. <ul>Messages - Payload </ul><ul><li>Minimal </li></ul><ul><ul><li>Just enough information and context for consumers to determine if updates is relevant to them
  231. 232. Consumer required to lookup any additional information required
  232. 233. Couples to services + point of failure </li></ul></ul><ul><li>Self contained </li></ul><ul><ul><li>Includes all information a consumer would require to process
  233. 234. Loosely coupled – no additional service interactions
  234. 235. Watch out for size – Amazon SQS is limited to 8k </li></ul></ul>
  235. 236. <ul>Messages - Correlation </ul><ul><li>Why it's required </li></ul><ul><ul><li>Troubleshooting – backtraces is always app local
  236. 237. Enforcing SLAs
  237. 238. Idempotency </li></ul></ul><ul><li>Helpful correlation id elements </li></ul><ul><ul><li>Source system
  238. 239. Destination system
  239. 240. /rails/user/234/session_dssasdadas/controller/action
  240. 241. Consider a “touch” mecanism – history of systems the
  241. 242. message has passed through </li></ul></ul>
  242. 243. <ul>QUESTIONS ? </ul>
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×