Microservices Budapest 2018: Long live the purple sticky! About policies, sagas and processes.

@martinschimak => May 8th, 2018 => Budapest => Microservices Meetup

Transcript

1. About policies, sagas and processes. @martinschimak -> May 8th, 2018 -> Budapest -> Microservices Meetup Long live the purple sticky! Order placed Request payment Policy?
3. Read Model Domain Event Aggregate Policy Command External System UI Command Invoked on raises raises Invoked on projected onto listened to by triggers triggers Inspired by the picture that explains (almost) everything :-) * *) © The ingenious Alberto Brandolini
4. Events are easy to grasp. Happy customers want facts! Goods shipped Order placed Goods fetched Payment received „We need to achieve some facts to create value for customers!“ Events are a concept easy to grasp for everybody in the room.
5. Domain events are prominently discussed – not just in DDD
6. The cool thing about events? They are facts. It already happened. Events let us look into the past. Payment received
7. Events create trust in a world of eventual consistency. Strong consistency Payment received Payment
8. Events help to decouple services. Order summary Payment received Payment UI raises projected onto Payment Service Order Service
9. Events help with cross-cutting concerns. Payment received Inform customer listened to by Payment Service Notification Service
10. Events are relaxed! Just happy to exist. :-)
11. Let‘s just rely on events in between services!
12. Relying on pure event choreographies Order placed Payment Service Payment received Inventory Service Goods fetched Shipment Service Goods shipped
13. Shipment Service Relying on events only leads to suboptimal coupling To change the order of two services, we touch 4 sticky notes… but wait, all three services! Goods shipped Order placed Inventory Service Payment Service Payment received Goods fetched
14. Who made the decision to use events only?
15. Our policies decide to act on facts – with commands Domain Event Policy Command listened to by triggers
16. Who owns the policy in a pure event choreography? Payment received Start Fetching Policy Fetch goods listened to by triggers Payment Service Inventory Service
17. Who owns the policy in a commanding approach? Payment received Start Fetching Policy Fetch goods listened to by triggers Payment Service Inventory Service
18. Neither of both truly „owns“ that policy? Payment received Fetch goods listened to by triggers Payment Service Inventory Service Start Fetching Policy
19. Extracting the policy into a mediator service Payment received Fetch goods listened to by triggers Payment Service Inventory Service Order Service Start Fetching Policy
20. The order as the company‘s core business Place order Order placed Request payment Order Service Payment received Fetch goods Goods fetched Ship goods Goods shipped “When the order is placed…” “When the payment is received…” “When the goods are fetched…” “Then we are done!” Mark order as fulfilled Order fulfilled Payment Service Inventory Service Shipment Service
21. Double check: what happens when we charge later? Place order Order placed Request payment Order Service Payment received Fetch goods Goods fetched Ship goods Goods shipped “When the order is placed…” “When the payment is received…” “When the goods are fetched…” “Then we are done!” Mark order as fulfilled Order fulfilled Payment Service Inventory Service Shipment Service “When the order is placed…” “When the payment is received…” “When the goods are fetched…”
22. Events decrease coupling? Often! Pro Tip: some commands may help, too!-)
23. Trade offs. Events and commands in between services… Payment received Policy Fetch goods listened to by triggers Payment Service Inventory Service Order Service
24. … do we introduce the central „god-like“ super service? Payment received Policy Fetch goods listened to by triggers Payment Service Inventory Service Order Service
25. Let‘s dig a bit deeper. Commands are intent. Nothing really happened so far. It‘s in the future. Place order
26. „Place order“ seen as an atomic transaction Domain Model Invoked on Order Placed raises Place order
27. When hugging a tree, it is difficult to see the wood!
28. „Place order“ seen as a multi-step service Order fulfilled Order canceled Payment received Goods shipped Place order Order placed From a client perspective, the service is „long-running“
29. Atomic vs. composite command execution Place order Order placed Typically we see a „command“ as the intent to change a write model... … but the customer‘s or service clients intent is often targeted at a more valuable business result, which needs many steps to be achieved. Place order Order fulfilled Atomic, trans- actional execution Composite, long- running execution
30. Is that command executable as a single, atomic step? Request payment
31. Let‘s do some event storming… Request payment Payment received Payment requested Charge credit card Depending on account balance Withdraw amount from account Amount Withdrawn Credit card charged Credit card failed Update credit card details Account details Credit card details updated Whenever card details are updated After two weeks Depending on the amount Amount credited Mark payment received Mark payment canceled Payment canceled Credit amount to account Whenever payment is canceled Mark payment received Payment received
32. Credit card gateway Accounting system Payment Request payment Charge credit card Credit card charged Our result seen as a collection of commands Withdraw amount from account Amount Withdrawn Amount credited Credit amount to account Mark payment Payment received Payment canceled Payment requested Credit card failed Update credit card details Credit card details updated Update credit card details Credit card details updated Credit card failed
33. What happens if we expose those atomic commands? Charge credit card Credit card charged Credit card failed Payment Service Retry with new credit card details Who owns the policy?
34. Payment seen as a „long-running“ multi-step service Request payment Payment received Payment Service
35. What happens if we expose troubles with some steps? Request payment Payment received Credit card failed Payment Service Retry with new credit card details Who owns the policy?
36. „Delegating our problems to our clients forces them to deal with the mitigation. They become god services.“ Credit card failed Retry with new credit card details Charge credit card listened to by triggers Payment Service Order Service
37. Smart endpoints (with dumb pipes) … … don‘t delegate problems they better deal with themselves!
38. A „long-running“ smart endpoint … Request payment Payment received Payment canceled 1) creates value – serving a result its client is really interested in 2) assumes responsibility – instead of delegating troubles with internal steps to its client 3) may go asynchronous – if needed for composite execution Payment Service
39. Long-running services help to protect proper boundaries Order service Payment service Request payment Payment canceled Payment received
40. How to get productive with long-running services?
41. Remember that events help to decouple services? Order summary Payment received Payment UI raises projected onto Payment Service Order Service
42. Decentral data management is enabled by events. Payment summary Payment received Payment raises projected onto Write Model Read Model Payment Service
43. Heavily inspired by Mathias Verraes! Thank you! Considering the CQRS pattern Read Model Projections Write Model Invariant Protection Client/Human Interaction Query Command Domain Event
44. Write Model Read Model Query Domain Event Command Observe Act Decide
45. Write Model Read Model Domain Event Command Domain Event Domain Event Domain Event Domain Event Event Sourcing Events as the source of truth Invariant Protection Events to (re-)project
46. How do we implement the payment service? Request payment Payment received Payment requested Charge credit card Depending on account balance Withdraw amount from account Amount Withdrawn Credit card charged Credit card failed Update credit card details Account details Credit card details updated Whenever card details are updated After two weeks Depending on the amount Amount credited Mark payment received Mark payment canceled Payment canceled Credit amount to account Whenever payment is canceled Mark payment received Payment received
47. Write Model Read Model Query Domain Event Command Decide Observe Act
48. Write Model Read Model Process Model Domain Event Command Query Policy plexiti de|coding domain language Observe Act Decide
49. Process Model Write Model Domain Event Command Process Manager Read Model Policy Observe Decide
50. How to get productive with process managers?
51. What are the „ingredients“ of process managers? Domain Event Payment Retrieval Payment Retrieval Stateful component instantiates or correlates Process state projects relevant event data onto listened to by Stateless component evaluates Policy Command triggers does nothing does nothing Timer Event schedules (iow waits for further events)
52. @Saga class Payment { private var paymentAmount = 0F @StartSaga @SagaEventHandler(associationProperty = "paymentId") fun on(event: PaymentRequested) { } } e.g. Axon Messaging & Saga Management is cool, but Java works as well! :-) 1) Correlate domain event 2) Save process state 3) Evaluate business policy 4) Create and issue command
53. An ecosystem of saga, state & process managers CADENCE Baker
54. Questions? @martinschimak
55. Thank you! @martinschimak