Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Martin Schimak

May 08, 2018
Tweet

More Decks by Martin Schimak

Other Decks in Programming

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. 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
  3. 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.
  4. The cool thing about events? They are facts. It already

    happened. Events let us look into the past. Payment received
  5. Events help to decouple services. Order summary Payment received Payment

    UI raises projected onto Payment Service Order Service
  6. Relying on pure event choreographies Order placed Payment Service Payment

    received Inventory Service Goods fetched Shipment Service Goods shipped
  7. 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
  8. Our policies decide to act on facts – with commands

    Domain Event Policy Command listened to by triggers
  9. Who owns the policy in a pure event choreography? Payment

    received Start Fetching Policy Fetch goods listened to by triggers Payment Service Inventory Service
  10. Who owns the policy in a commanding approach? Payment received

    Start Fetching Policy Fetch goods listened to by triggers Payment Service Inventory Service
  11. Neither of both truly „owns“ that policy? Payment received Fetch

    goods listened to by triggers Payment Service Inventory Service Start Fetching Policy
  12. Extracting the policy into a mediator service Payment received Fetch

    goods listened to by triggers Payment Service Inventory Service Order Service Start Fetching Policy
  13. 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
  14. 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…”
  15. Trade offs. Events and commands in between services… Payment received

    Policy Fetch goods listened to by triggers Payment Service Inventory Service Order Service
  16. … do we introduce the central „god-like“ super service? Payment

    received Policy Fetch goods listened to by triggers Payment Service Inventory Service Order Service
  17. Let‘s dig a bit deeper. Commands are intent. Nothing really

    happened so far. It‘s in the future. Place order
  18. „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“
  19. 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
  20. 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
  21. 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
  22. 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?
  23. 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?
  24. „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
  25. 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
  26. Long-running services help to protect proper boundaries Order service Payment

    service Request payment Payment canceled Payment received
  27. Remember that events help to decouple services? Order summary Payment

    received Payment UI raises projected onto Payment Service Order Service
  28. Decentral data management is enabled by events. Payment summary Payment

    received Payment raises projected onto Write Model Read Model Payment Service
  29. 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
  30. 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
  31. 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
  32. Write Model Read Model Process Model Domain Event Command Query

    Policy plexiti de|coding domain language Observe Act Decide
  33. 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)
  34. @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