1.
Break your event chains
MuCon, November 6th 2017, London
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/

3.
3 common hypotheses we check today:
# Events decrease coupling
# Central control needs to be avoided
# Workflow engines are painful

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.
Basic idea of dedicated, autonomous (micro-) services
Checkout
Payment
Inventory
Shipment
Dedicated Application Processes
Dedicated Persistence Backends
Dedicated Development Teams

8.
Events decrease coupling

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

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

11.
Events: Extract cross-cutting aspects
Checkout
Payment
Inventory
Shipment
„Inform the customer about
steps 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

12.
Events can decrease coupling*
*e.g. decentral data-management, read models,
extract cross-cutting aspects

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

14.
Events: peer-to-peer event choreographies
Fetch the
goods before
retrieving the
payment
Some
customers can
pay via invoice
…
Checkout
Payment
Inventory
Shipment
Good
fetched
Order
placed
Payment
received
Good
shipped

15.
Extract 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
Fetch the
goods before
retrieving the
payment
Some
customers can
pay via invoice
Payment
received
Retrieve
payment

16.
Events can increase coupling*
*e.g. complex peer-to-peer event chains

17.
Commands can decrease coupling*
*e.g. to avoid complex peer-to-peer event chains

18.
Central control needs to be avoided

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

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

21.
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?

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

23.
Ask: who is responsible to deal with problems?
Order
Credit
Card
Retrieve
Payment
Expired
A single central client of dumb endpoints
becomes a god service. Better: we create
several decentral, smart endpoints.
„If the credit
card expired, the
customer gets
another chance
to provide new
card details!“

24.
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 endpoints are
potentially long-running.”
Payment
Retrieve
Payment
Payment
received
„The client of a smart
endpoint remains lean.”

25.
Be sceptical about central control!*
*e.g. centralized ESB-like components or
god services which heavily interact with dumb endpoints

26.
But don‘t give up control!*
*e.g. miss to extract and control important
potentially long-running business capabilities

27.
The problem is not to command
services!
The problem is bad API design.

28.
Workflow engines are painful

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

30.
State machines
or workflow
engines
CADENCE
Baker

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

32.
Distributed systems

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

34.
Workflow
and
BPM

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

36.
Timeouts

37.
Compensation*

38.
Living documentation for long-running behaviour

39.
Focus on long-running behaviour - requiring state

40.
A visual HTML report for a specific test case

41.
Workflows live inside service boundaries

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

43.
Lightweight workflow engines are
great (and much better than DIY)*
*e.g. enabling potentially long-running services, solving hard
developer problems, can run decentralized

44.
Workflow engines can do (service)
orchestration.*
Orchestration is not about synchronous
request/response!
*We are not talking about container orchestration

45.
# Events decrease coupling: sometimes
read-models, no complex peer-to-peer event chains, don‘t forget commands
# Central control needs to be avoided: sometimes
no ESB, smart endpoints/dumb pipes, important capabilities need a home
# Workflow engines are painful: some of them
lightweight engines are easy to use and can run decentralized,
they solve hard developer problems, don‘t DIY

46.
Need some code?
InventoryPaymentOrder ShippingCheckout Monitor
https://github.com/flowing/flowing-retail/
Human
Tasks

47.
Thank you!

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

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