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