Web Form Automation for Bonterra Impact Management (fka Social Solutions Apri...
MuCon London 2017: Break your event chains
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
10. Request/Response: temporally coupled services
Checkout
Payment
Inventory
Shipment
„The button blinks green
if we can ship the item
within 24 hours!“
Request Response
11. 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
12. 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
14. 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
15. 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
16. 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
22. 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?
23. 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.
24. 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!“
25. 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.”
26. Be sceptical about central control!*
*e.g. centralized ESB-like components or
god services which heavily interact with dumb endpoints
27. But don‘t give up control!*
*e.g. miss to extract and control important
potentially long-running business capabilities
28. The problem is not to command
services!
The problem is bad API design.
30. Persist thing with
Entity, Actor, …
State machine or
workflow engine
DIY
Order
Credit
Card
Payment
Payment
received
How to
implement long-
running services?
45. Explicit flows help separate domain and infrastructure
Infrastructure
Aggregates,
Domain Events,
Domain Services,
etc …
+ the flow
Workflow
Engine
Payment
Application
Domain
46. Lightweight workflow engines are
great (and much better than DIY)*
*e.g. enabling potentially long-running services, solving hard
developer problems, can run decentralized
47. Workflow engines can do (service)
orchestration.*
Orchestration is not about synchronous
request/response!
*We are not talking about container orchestration
48.
49. # 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
52. 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
53. 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/