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.

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

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

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

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

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/

49. Define flows programatically or graphically

50. Define flows programatically or graphically
Todo…

51. Productive development and testing

52. Developer
friendly

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

57. The end-to-end process?

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!