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

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

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

2999fab21d182294fad0b2cc590fd54d?s=128

Martin Schimak

May 08, 2018
Tweet

Transcript

  1. About policies, sagas and processes. @martinschimak -> May 8th, 2018

    -> Budapest -> Microservices Meetup Long live the purple sticky! Order placed Request payment Policy?
  2. None
  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