Slides from the talk on 13th of November at the DDD Belgium Meetup in Gent/Brussels held together with Martin Schimak.

1. Events, Flows and
Long Running Services
Domain-Driven Design Belgium
Nov 13th 2017, Gent, Belgium
mail@bernd-ruecker.com
martin.schimak@plexiti.com
With thoughts from http://flowing.io
@berndruecker | @martinschimak

2. Bernd Rücker
Consultant & Dev. Advocate
10+ years workflow
Co-founder Camunda
http://bernd-ruecker.com/
Martin Schimak
Developer & Trainer, 10+ years
(de-)coding domain knowledge
DDDesign, TDD/BDD, EDA
http://plexiti.com/
http://flowing.io/

4. Simplified example:
dash button
Photo by 0xF2, available under Creative Commons BY-ND 2.0
license. https://www.flickr.com/photos/0xf2/29873149904/

5. Three steps…

6. Who is involved?
Checkout
Payment
Inventory
Shipment

7. „Events decrease coupling“?

8. Request/Response: temporally coupled services
Checkout
Payment
Inventory
Shipment
„The button blinks green
if we can ship the item
within 24 hours!“
Request Response

9. Events: temporal decoupling with read models
Checkout
Payment
Inventory
Shipment
„The button blinks green
if we can ship the item
within 24 hours!“
Events are facts about
what happened (in the past)
Good
Fetched
Good
Stored
Read
Model

10. Events: extracting or adding cross-cutting aspects
Checkout
Payment
Inventory
Shipment
„Inform the customer about
steps s/he is interested in!“
Order
placed
Payment
received
Good
shipped
Notify me when …
Order placed
Payment received
Good fetched
Good shipped
Customer
Mailings
Good
fetched

11. Events: peer-to-peer choreographies
Checkout
Payment
Inventory
Shipment
Order
placed
Payment
received
Good
shipped
„When the button is pressed, an
order is placed - and fulfilled!“
Good
fetched

12. Events: peer-to-peer choreographies
Please fetch
the goods
before waiting
for payment
Some
customers can
pay via invoice
Checkout
Payment
Inventory
Shipment
Good
fetched
Order
placed
Payment
received
Good
shipped

13. Extracting the end-to-end responsibility
Order
Checkout
Payment
Inventory
Shipment
Order
placed
Retrieve
payment
Commands have an
intent about what needs
to happen in the future
Please fetch
the goods
before waiting
for payment
Some
customers can
pay via invoice
Payment
received
Retrieve
payment

14. „Central control is bad“?

15. Checkout
Payment
Inventory
Shipment
Order
Order
placed
Payment
received
Good
fetched
Good
shipped
Smart ESB-like middleware

16. Checkout
Payment
Inventory
Shipment
Order
„Dumb“ messaging
„Smart endpoints and
dumb pipes!”
Martin Fowler

17. The danger of god services
Checkout
Payment
Inventory
Shipment
Order
„A few smart god services tell
anemic CRUD services what to do!”
Sam Newman
„Central“ order service
as bad as central ESB logic?

18. A god service is created by bad APIs
Checkout
Payment
Inventory
Shipment
Order
„Smart endpoints and
dumb pipes!”
Martin Fowler
Checkout
Payment
Inventory
Shipment
Smart endpoints
take care of a
business capability
their client does not
need to understand.

19. Ask: who is responsible to deal with problems?
Order
Credit
Card
Retrieve
Payment
Expired
The client of a dumb
service is forced to
deal with problems
which may actually be
none of his business.
„If the credit
card expired, the
customer gets
another chance
to provide new
card details!“

20. Ask: who is responsible to deal with problems?
Order
Credit
Card
„If the credit
card expired, the
customer gets
another chance
to provide new
card details!“
Expired
Smart services are
potentially long-running.
Payment
Retrieve
Payment
Payment
received
The client of a smart
service remains lean.

21. Some things in life
take time

22. Persist thing with
Entity, Actor, …
State machine or
workflow engine
DIY
Order
Credit
Card
Payment
Payment
received
How to
implement long-
running services?

23. „Workflow engines are painful“?

24. State machines
or workflow
engines
CADENCE
Baker

25. Workflow engines solve some hard developer problems
Monitoring &
Operations
Handling of time &
timeouts
Retry
Visibility &
Reporting
Versioning
Compensation
Message correlation &
deduplication
Performance &
scalability

26. Leaving the aggregate scope?

27. Workflow engines solve some hard developer problems
Monitoring &
Operations
Handling of time &
timeouts
Retry
Visibility &
Reporting
Versioning
Compensation
Message correlation &
deduplication
Performance &
scalability

28. Workflow
and
BPM #&?!

29. Live hacking

30. Bpmn.createProcess("order").executable()
//...
.sendTask().name("Retrieve payment").camundaClass(RetrievePayme
.receiveTask().name("Payment received").message("PaymentReceive
//...
{
"name": "retrieve_payment",
"tasks": [ {
"name": "Retrieve Payment",
"taskReferenceName": "payment",
"type": "SIMPLE",
...
Do you prefer coded or graphical DSLs?
* BPMN - ISO notation for modeling and
executing long-running processes and flows

31. Do you need a timeout?

32. Do you need a compensation? *

33. More complex flows - transparent and directly executable

34. Specifying and testing long-running behaviour

35. A visual test report for example #1 (Balance = 50, Amount = 70)

36. A visual test report for example #3 (Balance = 50, Amount = 30)

37. The binding strategy uses the step only when required

38. Living documentation for long-running behaviour

39. The DDD idea of ubiquitous language needs boundaries
Checkout
Payment
Inventory
Shipment
Ubiquitous
Language
Software
Experts
Domain
Experts
Useful models capturing
an “ubiquitous language”
need boundaries.

40. Workflows live inside service boundaries

41. Explicit flows help separate domain and infrastructure
Infrastructure
Aggregates,
Domain Events,
Domain Services,
etc …
+ the flow
Workflow
Engine
Payment
Application
Domain

42. Operational visibility in monitoring

43. Focus today:
executable software
(not domain exploration)

44. Example
InventoryPaymentOrder ShippingCheckout Monitor
https://github.com/flowing/flowing-retail/
Human
Tasks
H2 H2

45. Live hacking

47. New kid on the block
https://zeebe.io/
Zeebe
Broker
Your
application
Binary (MsgPack)
Support streaming & batching
Client
Horiziontally
scalable
Append only log / event sourcing
Peer-to-peer
cluster

48. 1. Events decrease coupling? Often! But not always.
e.g. events decrease coupling when used for read-models and cross-cutting concerns,
but: be careful to introduce complex peer-to-peer event chains – consider commands
2. Central control is bad? It can be! Respect the BC!
e.g. ESB smartness, god services often violate the odea of bounded contexts,
but: don‘t throw out the baby with the bath, important business capabilities need a home
3. Workflow engines are painful? Some of them!
e.g. with „zero coding“, when violating bounded contexts, but: lightweight engines
enable long-running services, run decentralized, solve hard developer problems

49. Thank you!

50. Code online:
https://github.com/flowing
Slides & Blog:
https://bernd-ruecker.com
https://plexiti.com
With thoughts from http://flowing.io
@berndruecker | @martinschimak
https://www.infoq.com
/articles/microservice-
event-choreographies

51. Images licensed from iStock
no attribution required
All icons licensed from Noun Project
no attribution required
Images licensed under Creative Commons license
Photo by 0xF2, available under
Creative Commons BY-ND 2.0 license.
https://www.flickr.com/photos/0xf2/2987
3149904/