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.

Long running processes in DDD

2,682 views

Published on

Talk given at DDDx London on 27th of April about how to implement long running processes in Domain Driven Design properly. Describes patterns like Process Manager and Saga.

Published in: Technology

Long running processes in DDD

  1. 1. Long running processes bernd.ruecker@camunda.com With thoughts from http://flowing.io @berndruecker | @martinschimak
  2. 2. AT&T
  3. 3. Assume you want to build a Dash button
  4. 4. pay receive shipment place order I want to have one item! I am happy!
  5. 5. Business Capabilities Bounded Contexts Order placed Shop Payment Shipping Business Outputs / Domain Events Inventory Payment received Goods picked Goods shipped
  6. 6. Implementation <<root entity>> Order - items - sum - customerId - ... <<value object>> Address - zipCode - ... 0..* <<event>> OrderCreated - orderItems - ...
  7. 7. Eventflow Order placed Payment received Goods fetched Goods shipped InventoryPayment ShippingShop
  8. 8. Process Manager
  9. 9. Process Manager • Do event command transformation • Implement the flow as 1st class citizen of domain logic • Handle state for long running flows
  10. 10. Process Manager • Do event command transformation • Implement the flow as 1st class citizen of domain logic • Handle state for long running flows
  11. 11. Let‘s zoom in the payment context Payment Order placed Payment received
  12. 12. Let‘s zoom in the payment context Payment Order placed Payment received The payment context has to listen to „order placed“ event
  13. 13. De-coupling? Payment Order placed Service fullfilled … Whenever a new client requires payment, the payment context has to be touched The payment context has to know all possible events that trigger a payment Subscription confirmed
  14. 14. Event command transformation Payment Retrieve payment Order placed Transformation Command Something has to happen in the future 1 recipient Event Something has happend in the past 0..n recipients
  15. 15. Order context Payment Retrieve payment Order placed Order
  16. 16. Event vs. command Payment Retrieve payment Order placed Order decide where to do the coupling
  17. 17. Vaughn Vernon „Process Managers transform Events into Commands“ At IDDD Workshop February 2017
  18. 18. Process Manager • Do event command transformation • Implement the flow as 1st class citizen of domain logic • Handle state for long running flows
  19. 19. Order context cares about the flow Payment Retrieve payment Order placed Order
  20. 20. The flow as graphical, but directly executable model
  21. 21. It is about visibility!
  22. 22. It is about ubiquitous language! Ubiquitous Language Software Experts Domain Experts
  23. 23. Martin Fowler Event notification is nice because it implies a low level of coupling, and is pretty simple to set up. It can become problematic, however, if there really is a logical flow that runs over various event notifications. The problem is that it can be hard to see such a flow as it's not explicit in any program text. Often the only way to figure out this flow is from monitoring a live system. This can make it hard to debug and modify such a flow. The danger is that it's very easy to make nicely decoupled systems with event notification, without realizing that you're losing sight of that larger-scale flow, and thus set yourself up for trouble in future years https://martinfowler.com/articles/201701-event-driven.html
  24. 24. New business requirements Order placed Payment received Goods fetched Goods shipped InventoryPayment ShippingShop VIP customers can order with invoice (and pay later)
  25. 25. New business requirements Order placed Payment received Goods fetched Goods shipped InventoryPayment ShippingShop VIP customers can order with invoice (and pay later) If VIP customer If not VIP customer Order billed Billing If VIP customer
  26. 26. Adjusted flow
  27. 27. I was inspired by Greg Young's course at Skills Matter, see CQRS/DDD course. […] The problem with our first implementation is that it misses a concept: there is no notion of a process. In earlier solutions the process was hidden in the sense that whenever a service thought it couldn't proceed, it would send out a message. E.g. Shop would say it had a completed Order. This Order would then be picked up by Payment and Fulfillment. Payment would allow a customer to pay and Fulfillment would have to wait because it needed paid Orders. So when Payment was done it would send out a PaymentReceived message that would allow Fulfillment to continue. This works but Greg argues that this allows only a single process and that the solution would be more flexible if we would have a process manager that delegates steps in the process to different services, waiting for them to complete. http://blog.xebia.com/refactoring-to-microservices-introducing-a-process-manager/
  28. 28. Process Manager • Do event command transformation • Implement the flow as 1st class citizen of domain logic • Handle state for long running flows
  29. 29. Example Long running, requires state handling Potentially long running, requires state handling
  30. 30. Long running flows have state
  31. 31. In DDD everything leaving the aggregate scope is potentially long running
  32. 32. Saga The classical Saga pattern example book hotel book car book flight cancel hotel cancel car 1. 2. 3. 5.6. 4. In case of failure trigger compensations book trip
  33. 33. How to implement?
  34. 34. Reactive actor with Akka https://github.com/VaughnVernon/ReactiveMessagingPatterns_ActorModel/blob/master/src /co/vaughnvernon/reactiveenterprise/processmanager/ProcessManager.scala#L91
  35. 35. State in entity
  36. 36. Routing slip http://vasters.com/archive/Sagas.html
  37. 37. State machine http://camunda.org/
  38. 38. Logic remains in normal code
  39. 39. Tools provide persistent state, visibility and more
  40. 40. Compensation
  41. 41. The power of graphics Graphics Code http://vasters.com/archive/Sagas.html
  42. 42. Smells like „BPM“?
  43. 43. The 7 sins of workflow and Java Zero-code suites Homegrown engine No engine Wrong engine Wrong usage 4 6 5 7 http://blog.bernd-ruecker.com/
  44. 44. Death by properties panel Script: Please enter your complex code here. (Without IDE support of course!)
  45. 45. BPM Suites By the way, we introduce an own development approach, IDE, version control, user management, reporting, …
  46. 46. Zero code & developers We have a lot of problems! It totally sucks! I hate BPM!
  47. 47. Bernd Rücker Consultant & Evangelist > 10+ years workflow http://bernd-ruecker.com/ bernd.ruecker@camunda.com Co-founder Camunda http://camunda.org/
  48. 48. Define flows programatically or graphically
  49. 49. Define flows programatically or graphically Todo…
  50. 50. Productive development and testing
  51. 51. Developer friendly
  52. 52. Do it yourself? Actor Entity Routing Slip © Picture from http://www.windtraveler.net/2010_06_01_archive.html
  53. 53. Think about subsequent requirements Monitoring & Operations Visibility Versioning Time & Timeouts Domain Logic
  54. 54. Think about what you miss
  55. 55. The 7 sins of workflow Zero-code suites Homegrown engine Granularity bloopers BPM monolith Stakeholders habitat violation Over engineering No engine Wrong engine Wrong usage http://blog.bernd-ruecker.com/ 4 5 7
  56. 56. The end-to-end process?
  57. 57. You are not forced to violate the bounded context! Order Feedback Inventory Payment
  58. 58. Payment Local flows in the bounded contexts Order
  59. 59. Lightweight and embeddable engine Engine must be • easy to use • developer friendly also in the scope of multiple scopes/aggregates/services • technically • license model Payment Order engine engine … Inventory Shipping … engine
  60. 60. The 7 sins of workflow Zero-code suites Homegrown engine Granularity bloopers BPM monolith No engine Wrong engine Wrong usage http://blog.bernd-ruecker.com/ 5 7
  61. 61. Slides are nice – but what about code? Sure: http://github.com/flowing/
  62. 62. Demo architecture InventoryPaymentOrder Shipping H2 Shop Monitor Camunda Webapp on Tomcat for demo in single Java VM for simplicity http://flowing.io/
  63. 63. Flows that cross aggregate boundaries State Routing Slip Entity State machine or embeddable workflow engine Actor Clear ownership and proper couplingThe problem Use Cases Implemenation approaches Possible advantages Monitoring & Operations Visibility Ubiquitious language Handling of time & timeouts Save effort Versioning Saga Human Task Management Service Collaboration Requirements
  64. 64. Lightweight state machines or workflow engines are not evil! They help you solve some coding problems well.
  65. 65. Code online: https://github.com/flowing Slides online: http://bernd-ruecker.com Feedback: http://bernd-ruecker.com/feedback With thoughts from http://flowing.io @berndruecker | @martinschimak
  66. 66. Thank you!

×