Long running processes in DDD
17 likes8,417 views
The document discusses the importance of managing long-running processes in software development, emphasizing the role of process managers that transform events into commands and handle state effectively. It critiques reliance on simplistic event notifications, which can obscure the larger operational flow and complicate debugging and modification. Additionally, it highlights challenges related to business requirements, such as payments and fulfillment for VIP customers, and advocates for programmatic or graphical flow definitions to enhance developer experience and system visibility.
![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/](https://image.slidesharecdn.com/2017-04-27dddx-170427133244/85/Long-running-processes-in-DDD-27-320.jpg)
Long running processes in DDD
- 1. Long running processes bernd.ruecker@camunda.com With thoughts from http://flowing.io @berndruecker | @martinschimak
- 2. AT&T
- 3. Assume you want to build a Dash button
- 4. pay receive shipment place order I want to have one item! I am happy!
- 5. Business Capabilities Bounded Contexts Order placed Shop Payment Shipping Business Outputs / Domain Events Inventory Payment received Goods picked Goods shipped
- 6. Implementation <<root entity>> Order - items - sum - customerId - ... <<value object>> Address - zipCode - ... 0..* <<event>> OrderCreated - orderItems - ...
- 7. Eventflow Order placed Payment received Goods fetched Goods shipped InventoryPayment ShippingShop
- 9. Process Manager • Do event command transformation • Implement the flow as 1st class citizen of domain logic • Handle state for long running flows
- 10. Process Manager • Do event command transformation • Implement the flow as 1st class citizen of domain logic • Handle state for long running flows
- 11. Let‘s zoom in the payment context Payment Order placed Payment received
- 12. Let‘s zoom in the payment context Payment Order placed Payment received The payment context has to listen to „order placed“ event
- 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. 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
- 16. Event vs. command Payment Retrieve payment Order placed Order decide where to do the coupling
- 17. Vaughn Vernon „Process Managers transform Events into Commands“ At IDDD Workshop February 2017
- 18. Process Manager • Do event command transformation • Implement the flow as 1st class citizen of domain logic • Handle state for long running flows
- 19. Order context cares about the flow Payment Retrieve payment Order placed Order
- 20. The flow as graphical, but directly executable model
- 21. It is about visibility!
- 22. It is about ubiquitous language! Ubiquitous Language Software Experts Domain Experts
- 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. New business requirements Order placed Payment received Goods fetched Goods shipped InventoryPayment ShippingShop VIP customers can order with invoice (and pay later)
- 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. Adjusted flow
- 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. Process Manager • Do event command transformation • Implement the flow as 1st class citizen of domain logic • Handle state for long running flows
- 29. Example Long running, requires state handling Potentially long running, requires state handling
- 30. Long running flows have state
- 31. In DDD everything leaving the aggregate scope is potentially long running
- 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
- 34. Reactive actor with Akka https://github.com/VaughnVernon/ReactiveMessagingPatterns_ActorModel/blob/master/src /co/vaughnvernon/reactiveenterprise/processmanager/ProcessManager.scala#L91
- 35. State in entity
- 38. Logic remains in normal code
- 39. Tools provide persistent state, visibility and more
- 40. Compensation
- 41. The power of graphics Graphics Code http://vasters.com/archive/Sagas.html
- 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. Death by properties panel Script: Please enter your complex code here. (Without IDE support of course!)
- 45. BPM Suites By the way, we introduce an own development approach, IDE, version control, user management, reporting, …
- 46. Zero code & developers We have a lot of problems! It totally sucks! I hate BPM!
- 47. Bernd Rücker Consultant & Evangelist > 10+ years workflow http://bernd-ruecker.com/ bernd.ruecker@camunda.com Co-founder Camunda http://camunda.org/
- 49. Define flows programatically or graphically
- 50. Define flows programatically or graphically Todo…
- 51. Productive development and testing
- 53. Do it yourself? Actor Entity Routing Slip © Picture from http://www.windtraveler.net/2010_06_01_archive.html
- 54. Think about subsequent requirements Monitoring & Operations Visibility Versioning Time & Timeouts Domain Logic
- 55. Think about what you miss
- 56. 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
- 58. You are not forced to violate the bounded context! Order Feedback Inventory Payment
- 59. Payment Local flows in the bounded contexts Order
- 60. 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
- 61. 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
- 62. Slides are nice – but what about code? Sure: http://github.com/flowing/
- 63. Demo architecture InventoryPaymentOrder Shipping H2 Shop Monitor Camunda Webapp on Tomcat for demo in single Java VM for simplicity http://flowing.io/
- 64. 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
- 65. Lightweight state machines or workflow engines are not evil! They help you solve some coding problems well.
- 66. 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
- 67. Thank you!