Download as PDF, PPTX
![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)
Uploaded byBernd Ruecker
Long running processes in DDD
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.
More Related Content
Similar to Long running processes in DDD
Long running processes in DDD
- 1. Long running processes bernd.ruecker@camunda.com Withthoughts from http://flowing.io @berndruecker | @martinschimak
- 2.
- 3. Assume you want tobuild a Dash button
- 4. pay receive shipment place order I wantto have one item! I am happy!
- 5. Business Capabilities Bounded Contexts Order placed Shop PaymentShipping 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.
- 8.
- 9. Process Manager • Doevent command transformation • Implement the flow as 1st class citizen of domain logic • Handle state for long running flows
- 10. Process Manager • Doevent command transformation • Implement the flow as 1st class citizen of domain logic • Handle state for long running flows
- 11. Let‘s zoom inthe payment context Payment Order placed Payment received
- 12. Let‘s zoom inthe 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 newclient 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 placedTransformation Command Something has to happen in the future 1 recipient Event Something has happend in the past 0..n recipients
- 15.
- 16. Event vs. command Payment Retrieve payment Order placedOrder decide where to do the coupling
- 17. Vaughn Vernon „Process Managers transformEvents into Commands“ At IDDD Workshop February 2017
- 18. Process Manager • Doevent command transformation • Implement the flow as 1st class citizen of domain logic • Handle state for long running flows
- 19. Order context caresabout the flow Payment Retrieve payment Order placed Order
- 20. The flow asgraphical, but directly executable model
- 21. It is aboutvisibility!
- 22. It is aboutubiquitous language! Ubiquitous Language Software Experts Domain Experts
- 23. Martin Fowler Event notificationis 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 InventoryPaymentShippingShop VIP customers can order with invoice (and pay later)
- 25. New business requirements Order placed Payment received Goods fetched Goods shipped InventoryPaymentShippingShop VIP customers can order with invoice (and pay later) If VIP customer If not VIP customer Order billed Billing If VIP customer
- 26.
- 27. I was inspiredby 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 • Doevent command transformation • Implement the flow as 1st class citizen of domain logic • Handle state for long running flows
- 29. Example Long running, requires statehandling Potentially long running, requires state handling
- 30. Long running flowshave state
- 31. In DDD everythingleaving the aggregate scope is potentially long running
- 32. Saga The classical Sagapattern 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.
- 34. Reactive actor withAkka https://github.com/VaughnVernon/ReactiveMessagingPatterns_ActorModel/blob/master/src /co/vaughnvernon/reactiveenterprise/processmanager/ProcessManager.scala#L91
- 35.
- 36.
- 37.
- 38. Logic remains innormal code
- 39. Tools provide persistentstate, visibility and more
- 40.
- 41. The power ofgraphics Graphics Code http://vasters.com/archive/Sagas.html
- 42.
- 43. The 7 sinsof 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 propertiespanel Script: Please enter your complex code here. (Without IDE support of course!)
- 45. BPM Suites By theway, 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 programaticallyor graphically
- 50. Define flows programaticallyor graphically Todo…
- 51. Productive development andtesting
- 52.
- 53. Do it yourself?Actor Entity Routing Slip © Picture from http://www.windtraveler.net/2010_06_01_archive.html
- 54. Think about subsequentrequirements Monitoring & Operations Visibility Versioning Time & Timeouts Domain Logic
- 55. Think about whatyou miss
- 56. The 7 sinsof 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
- 57.
- 58. You are notforced to violate the bounded context! Order Feedback Inventory Payment
- 59. Payment Local flows inthe bounded contexts Order
- 60. Lightweight and embeddableengine 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 sinsof 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 ShopMonitor 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 Statemachine 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 machinesor 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 Withthoughts from http://flowing.io @berndruecker | @martinschimak
- 67.