Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

KanDDDinsky: Let your domain events flow

711 views

Published on

Slides from my talk with Martin Schimak at KanDDDinsky on 20th of October 2017 in Berlin.

Published in: Technology

KanDDDinsky: Let your domain events flow

  1. 1. Let your domain events flow KanDDDinsky, Oct 20th, 2017, Berlin, Germany mail@bernd-ruecker.com martin.schimak@plexiti.com With thoughts from http://flowing.io @berndruecker | @martinschimak
  2. 2. Bernd Rücker Consultant & Dev. Advocate 10+ years workflow Co-founder Camunda http://bernd-ruecker.com/ Martin Schimak Developer & Trainer, 10+ years (de-)coding domain knowledge DDDesign, TDD/BDD, EDA http://plexiti.com/ http://flowing.io/
  3. 3. Simplified example: dash button Photo by 0xF2, available under Creative Commons BY-ND 2.0 license. https://www.flickr.com/photos/0xf2/29873149904/
  4. 4. Three steps…
  5. 5. Who is involved? Checkout Payment Inventory Shipment
  6. 6. Looking into events… Checkout Payment Inventory Shipment Domain Events are facts that happened in the pastGood Fetched Good Stored Read Model Write Model „The button blinks green if we can ship the item within 24 hours!“
  7. 7. Peer-to-peer event flows Checkout Payment Inventory Shipment Payment received Order placed Goods fetched
  8. 8. Peer-to-peer event flows Checkout Payment Inventory Shipment Payment received Order placed Goods fetched Please fetch the goods before waiting for payment Some customers can pay via invoice …
  9. 9. Some requirements don‘t fit anywhere… What are we missing? Order Checkout Payment Inventory Shipment
  10. 10. Commands can decrease coupling Order Checkout Payment Inventory Shipment Order placed Retrieve payment Commands have an intent about what needs to happen in the future Please fetch the goods before waiting for payment Some customers can pay via invoice Payment received Retrieve payment
  11. 11. Good API design respects responsibility boundaries Order Checkout Payment Inventory Shipment „A few smart god services tell anemic CRUD services what to do!” Sam Newman What is the payment service responsible for?
  12. 12. Some things in life take time
  13. 13. A customer can update an expired credit card within two weeks before we cancel his order „
  14. 14. Payment requires persitent state Order
  15. 15. Pass around state as „routing slip“ Persist state with Entity, Actor, … State machine How to implement a Process Manager? DIY DIY
  16. 16. State machine Persistent thing (Entity, Actor, …) Routing slip CADENCE Baker
  17. 17. State machines solve some hard developer problems Monitoring & Operations Handling of time & timeouts Retry Visibility & Reporting Versioning Compensation Message correlation & deduplication Performance & scalability
  18. 18. Leaving the aggregate scope?
  19. 19. State machines solve some hard developer problems Monitoring & Operations Handling of time & timeouts Retry Visibility & Reporting Versioning Compensation Message correlation & deduplication Performance & scalability
  20. 20. Bpmn.createProcess("order").executable() //... .sendTask().name("Retrieve payment").camundaClass(RetrievePayme .receiveTask().name("Payment received").message("PaymentReceive //... { "name": "retrieve_payment", "tasks": [ { "name": "Retrieve Payment", "taskReferenceName": "payment", "type": "SIMPLE", ... Do you prefer coded or graphical DSLs? * BPMN - ISO notation for modeling and executing long-running processes and flows
  21. 21. Do you need a timeout?
  22. 22. Do you need a compensation? *
  23. 23. BPM?
  24. 24. Flows done right Developer friendly Lightweight & composable BizDevOps
  25. 25. More complex flows - transparent and directly executable
  26. 26. Specifying and testing long-running behaviour
  27. 27. A visual test report for example #1 (Balance = 50, Amount = 70)
  28. 28. A visual test report for example #3 (Balance = 50, Amount = 30)
  29. 29. The binding strategy uses the step only when required
  30. 30. Living documentation for long-running behaviour
  31. 31. Explicit language help in tackling complex event flows Ubiquitous Language Software Experts Domain Experts
  32. 32. Explicit flows help sepatrate domain and infrastructure Ports and Adapters Application Domain Aggregates, Domain Events, Domain Services, etc … + the flow State machine
  33. 33. Flows live inside the context boundaries
  34. 34. Example InventoryPaymentOrder ShippingCheckout Monitor https://github.com/flowing/flowing-retail/ Human Tasks
  35. 35. Live hacking
  36. 36. Operational visibility in monitoring – possibly end-to-end
  37. 37. Mitigate tight coupling Consider core capabilities Leverage state machines Decentralize
  38. 38. Thank you!
  39. 39. Code online: https://github.com/flowing Slides & Blog: https://bernd-ruecker.com https://plexiti.com With thoughts from http://flowing.io @berndruecker | @martinschimak https://www.infoq.com /articles/microservice- event-choreographies
  40. 40. Images licensed from iStock no attribution required All icons licensed from Noun Project no attribution required Images licensed under Creative Commons license Photo by 0xF2, available under Creative Commons BY-ND 2.0 license. https://www.flickr.com/photos/0xf2/2987 3149904/

×