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

8. Process Manager

9. 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

15. Order context Payment Retrieve payment Order placed Order

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

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/

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

33. How to implement?

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

36. Routing slip http://vasters.com/archive/Sagas.html

37. State machine http://camunda.org/

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

42. Smells like „BPM“?

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/

48. Define flows programatically or graphically

49. Define flows programatically or graphically Todo…

50. Productive development and testing

51. Developer friendly

53. Think about subsequent requirements Monitoring & Operations Visibility Versioning Time & Timeouts Domain Logic

54. Think about what you miss

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. The end-to-end process?

57. You are not forced to violate the bounded context! Order Feedback Inventory Payment

58. Payment Local flows in the bounded contexts Order

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. 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. Slides are nice – but what about code? Sure: http://github.com/flowing/

62. Demo architecture InventoryPaymentOrder Shipping H2 Shop Monitor Camunda Webapp on Tomcat for demo in single Java VM for simplicity http://flowing.io/

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. Lightweight state machines or workflow engines are not evil! They help you solve some coding problems well.

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. Thank you!

Long running processes in DDD

Bernd Ruecker

Long running processes in DDD