$30 off During Our Annual Pro Sale. View Details »

Know the flow! Events, commands and long-running services.

Know the flow! Events, commands and long-running services.

@martinschimak -> Oct 4th, 2018 -> Microservices Munich

Martin Schimak

October 04, 2018
Tweet

More Decks by Martin Schimak

Other Decks in Programming

Transcript

  1. Events, commands and long-running services
    Oct 4th, 2018 -> Munich -> Microservices Meetup
    Know
    the flow!
    @martinschimak

    View Slide

  2. Commands Events
    @martinschimak
    and
    Retrieve
    payment
    Payment
    retrieved

    View Slide

  3. vs
    Orchestration Choreography
    Long-running
    services

    View Slide

  4. Events look into the past
    „An event is something that
    has happened in the past.“
    - Greg Young
    Payment
    retrieved
    @martinschimak

    View Slide

  5. Commands look into the future
    A command specifies something
    that should happen in the future.
    Retrieve
    payment
    @martinschimak

    View Slide

  6. Commands and events. And intent.
    „Commands are all about
    intent.
    - Jonas Bonér
    @martinschimak
    Events have no intent.“
    Intent
    Retrieve
    payment
    Payment
    retrieved
    Outcome

    View Slide

  7. Commands and events. Like two sides of a coin?
    Payment
    retrieved
    Payment
    retrieval
    Intent Outcome
    Execution
    Something should happen Something happens Something happened
    Retrieve
    payment
    @martinschimak

    View Slide

  8. Order
    fulfillment
    Commands and events. Flipping the coin?
    Payment
    retrieved
    Outcome Execution
    Something happens
    Something happened
    @martinschimak
    Intent
    Something should happen
    Fetch
    goods

    View Slide

  9. Domain events are more explicitly discussed than commands
    @martinschimak

    View Slide

  10. Events are really simple to grasp ...
    Goods
    shipped
    Order
    placed
    Goods
    fetched
    Payment
    retrieved
    ... EventStorming!
    @martinschimak

    View Slide

  11. EventStorming! When it starts to get interesting! :-)
    @martinschimak

    View Slide

  12. Events to separate write and read models ...
    Order
    summary
    Payment
    retrieved
    Payment UI
    raises
    projected
    onto
    ... CQRS!
    @martinschimak

    View Slide

  13. Events to temporally decouple services ...
    Order
    summary
    Payment
    retrieved
    Payment UI
    raises
    projected
    onto
    Payment Service
    Order Service
    ... CQRS with „foreign“ events!
    @martinschimak

    View Slide

  14. Events to represent history and state of systems ...
    Payment
    received
    Payment
    Payment
    received
    Payment
    received
    Payment
    received
    Payment
    retrieved
    ... Event Sourcing!
    @martinschimak

    View Slide

  15. Events to enable whole business processes ...
    ... Event
    choreographies!
    Payment
    received
    Inform
    customer
    listened to by
    Payment Service
    Notification Service
    @martinschimak

    View Slide

  16. Let‘s just rely on events in between services!
    @martinschimak

    View Slide

  17. Payment Service Credit Card
    Gateway
    @martinschimak

    View Slide

  18. Item
    ordered
    My context of sophisticated fulfillments
    Energy
    traded
    Order
    fulfillment
    Energy trade
    execution
    Coverage
    extension
    requested
    Policy
    issuance
    @martinschimak

    View Slide

  19. plexiti.com
    @martinschimak

    View Slide

  20. Eric Evans, 2004

    View Slide

  21. 2004 2006 2008 2018
    2010 2012 2014 2016
    London Amsterdam Denver
    Berlin
    ?
    Vienna

    View Slide

  22. 2004 2006 2008 2018
    2010 2012 2014 2016
    ?

    View Slide

  23. New pair
    of shoes
    ordered
    End-to-end business processes and their phases
    New pair
    of shoes
    ordered
    Old pair
    of shoes
    worn out
    Order new
    pair of
    shoes
    New pair
    of shoes
    delivered
    Order Fulfillment
    History
    Customer-driven Supplier-driven
    Supplier-exploring
    Human to Machine
    Supporting Service
    Customer-determined
    Machine to Machine
    Automated Service
    @martinschimak

    View Slide

  24. A company‘s „long-running“ order fulfillment service
    Order new
    pair of
    shoes
    New pair
    of shoes
    delivered
    Domain
    Command
    Domain
    Event
    “Long-running”
    service
    Order
    fulfillment
    service
    Supplier-driven
    Customer-determined
    Machine to Machine
    Automated Service
    @martinschimak

    View Slide

  25. „Long-running“ services have long-running contracts
    Order new
    pair of
    shoes
    New pair
    of shoes
    delivered
    Order
    fulfillment
    service
    “Long-running”
    service
    “Long-running”
    asynchronous contract
    Hours to weeks
    @martinschimak
    Domain
    Command
    Domain
    Event

    View Slide

  26. „Long-running“ services may have internal customers
    Retrieve
    payment
    Payment
    retrieved
    Payment
    service
    “Long-running”
    service
    Seconds to weeks
    @martinschimak
    “Long-running”
    asynchronous contract
    Domain
    Command
    Domain
    Event

    View Slide

  27. „Long-running“ services with fine-grained contracts
    Charge
    credit card
    Credit card
    charged
    Credit card
    gateway
    “Long-running”
    service
    1 to 20 seconds
    @martinschimak
    “Long-running”
    asynchronous contract
    Domain
    Command
    Domain
    Event

    View Slide

  28. Order Service
    Order
    placed
    Payment Service
    Payment
    retrieved
    Inventory Service
    Goods
    fetched
    Shipment Service
    Goods
    shipped
    The choreography principle
    @martinschimak

    View Slide

  29. Payment Service Inventory Service Shipment Service
    The orchestration principle
    Order Service
    Fetch
    goods
    Retrieve
    payment
    Ship
    goods

    View Slide

  30. This is how the story is often presented …
    Choreo-
    graphy
    Orches-
    tration
    Process logic Process control
    explicit central
    implicit decentral
    Service coupling
    high
    low
    @martinschimak

    View Slide

  31. Order Service
    Order
    placed
    Payment Service
    Payment
    retrieved
    Inventory Service
    Goods
    fetched
    Shipment Service
    Goods
    shipped
    Choreographies and their implicit process logic ...
    @martinschimak

    View Slide

  32. Order Service Payment Service Inventory Service Shipment Service
    Order
    placed
    Goods
    shipped
    ... can lead to a hidden form of accidental coupling
    Payment Service
    Inventory Service
    Goods
    fetched
    Payment
    retrieved
    ... to change implicit process logic ...
    Change
    listener 1 ...
    Change
    listener 2 ...
    Change
    listener 3 ...
    @martinschimak

    View Slide

  33. Payment Service Inventory Service Shipment Service
    Orchestration and its explicit process logic ...
    Order Service
    Fetch
    goods
    Retrieve
    payment
    Ship
    goods
    ... does not display THIS form of
    hidden accidental coupling...

    View Slide

  34. Who made the decision to use events only?
    @martinschimak

    View Slide

  35. This is how the story develops …
    Choreo-
    graphy
    Orches-
    tration
    Process logic Process control
    explicit central
    implicit decentral
    Service coupling
    high
    low
    Not
    necessarily
    Not
    necessarily
    @martinschimak

    View Slide

  36. Let‘s dig a bit deeper and look into this ...
    Choreo-
    graphy
    Orches-
    tration
    Process logic Process control
    explicit central
    implicit decentral
    Service coupling
    high
    low
    Not
    necessarily
    Not
    necessarily
    @martinschimak

    View Slide

  37. Comparing unhealthy apples and healthy oranges
    š Maybe Synchronous
    š Request and Response Style
    š Sender/Receiver Exchange
    š Probably Transient
    š Asynchronous by Nature
    š Fire and Forget Style
    š Publish/Subscribe Exchange
    š Probably Persistent
    Command Event
    @martinschimak

    View Slide

  38. Payment Service Inventory Service Shipment Service
    Why not asynchronous commands? „Doable“ ...
    Order Service
    Fetch
    goods
    Retrieve
    payment
    Ship
    goods
    Request
    Async Response
    Request Async
    Response
    Async Response
    Request

    View Slide

  39. How unhealthy is this apple ...
    š Maybe Synchronous
    š Request and Response Style
    š Sender/Receiver Exchange
    š Probably Transient
    š Asynchronous by Nature
    š Fire and Forget Style
    š Publish/Subscribe Exchange
    š Probably Persistent
    Command Event
    Or Asynchronous!
    @martinschimak

    View Slide

  40. ?
    ? ?
    Payment Service Inventory Service Shipment Service
    Why not fire the command? And listen to an event?
    Order Service
    Fetch
    goods
    Retrieve
    payment
    Ship
    goods
    Payment
    retrieved
    Goods
    fetched
    Goods
    shipped
    Order
    fulfilled
    Fire
    Fire Fire
    Listen
    Listen Listen

    View Slide

  41. How unhealthy is this apple ...
    š Maybe Synchronous
    š Request and Response Style
    š Sender/Receiver Exchange
    š Probably Transient
    š Asynchronous by Nature
    š Fire and Forget Style
    š Publish/Subscribe Exchange
    š Probably Persistent
    Command Event
    Or Asynchronous!
    Like Fire and Listen?
    @martinschimak

    View Slide

  42. ?
    Payment Service
    Why not publish the command?
    Order Service
    Retrieve
    payment
    Payment
    retrieved
    Publish
    @martinschimak

    View Slide

  43. ?
    Payment Service
    ... we get location transparency inside a context ...
    Order Service
    Retrieve
    payment
    Payment
    retrieved
    Publish
    Subscribe
    Financial Services
    Bounded Context
    @martinschimak

    View Slide

  44. ?
    Payment Service
    ... and the ability to subscribe to „everything“.
    Order Service
    Retrieve
    payment
    Payment
    retrieved
    Publish
    Subscribe
    Financial Services
    Bounded Context
    Subscribe
    Subscribe
    Business Monitoring
    Bounded Context
    „Order Context wanted
    payment to happen!“
    „Financial
    Context retrieved
    payment!“

    View Slide

  45. The apple doesn’t look so unhealthy anymore ...
    š Maybe Synchronous
    š Request and Response Style
    š Sender/Receiver Exchange
    š Probably Transient
    š Asynchronous by Nature
    š Fire and Forget Style
    š Publish/Subscribe Exchange
    š Potentially Persistent
    Command Event
    Or Asynchronous!
    Like Fire and Listen?
    Like Publish and
    Promise to Subscribe?
    @martinschimak

    View Slide

  46. What about focusing on semantical differences only …
    š We specified an intent
    š This just models our “state of mind”
    š We use imperative tense to express intent
    š Defined by supplier bounded context,
    created by customer system
    š We created an outcome
    š This models everybody’s “state of world”
    š We use past tense to express an outcome
    š Defined and created by emitter bounded
    context and system
    Command Event
    @martinschimak

    View Slide

  47. ?
    Payment Service
    Related semantics are both defined in supplier context
    Retrieve
    payment
    Payment
    retrieved
    Financial Services
    Bounded Context
    „When YOU send
    this WE promise to
    receive and act!“
    „When WE send this
    YOU decide to
    receive and act!“
    Command Event
    @martinschimak
    Make the
    contract explicit!

    View Slide

  48. and
    Apples Oranges
    @martinschimak

    View Slide

  49. @martinschimak
    „Atomic“
    Execution
    Command
    Intent
    Something should happen
    Domain
    Event
    Outcome
    Something happened

    View Slide

  50. @martinschimak
    „Composite“
    Execution
    Domain
    Command
    Intent
    Something should happen
    Domain
    Event
    Outcome
    Something happened

    View Slide

  51. ?
    Payment Service
    Mix and match decentral orchestration and choreography
    Retrieve
    payment
    Payment
    retrieved
    Financial
    Context
    Command
    Event
    Order Service
    Fulfillment
    Context
    Payment
    retrieval
    failed
    Event
    Marketing
    Context
    Customer
    promoted
    Promotions
    service
    Event
    @martinschimak

    View Slide

  52. New pair
    of shoes
    ordered
    It‘s a supplier‘s responsibility to act on customer intent
    New pair
    of shoes
    ordered
    Retrieve
    payment
    Payment
    retrieved
    Domain
    Events
    Customer Supplier
    Payment Service
    @martinschimak
    Domain
    Command
    Domain
    Event

    View Slide

  53. New pair
    of shoes
    ordered
    It‘s a customer‘s responsibility to specify intent
    New pair
    of shoes
    ordered
    Retrieve
    payment
    Domain
    Events
    Customer Supplier
    Order
    placed
    Order Service
    @martinschimak
    Domain
    Command
    Domain
    Event

    View Slide

  54. New pair
    of shoes
    ordered
    Some responsibilities span both phases, but not all
    New pair
    of shoes
    ordered
    Promote
    customer
    Domain
    Events
    Payment
    retrieved
    Promotions
    service
    Customer
    promoted
    Promotions
    service
    @martinschimak
    Domain
    Command
    Domain
    Event

    View Slide

  55. Wait. It really depends ... on organizational responsibilities?
    @martinschimak

    View Slide

  56. Orchestration and choreography... „it really depends“.
    Choreo-
    graphy
    Orches-
    tration
    Process logic Process control
    explicit central
    implicit decentral
    Service coupling
    high
    low
    Not
    necessarily
    Not
    necessarily
    Not
    necessarily
    Not
    necessarily
    @martinschimak

    View Slide

  57. Embed and contain state managing business logic!
    Retrieve
    payment
    Payment
    retrieved
    Payment
    service
    “Long-running”
    service
    Seconds to weeks
    Payment
    retrieval
    failed
    @martinschimak
    Domain
    Command
    Domain
    Event

    View Slide

  58. “Process” is NOT horizontal!
    It is VERTICAL, too
    @martinschimak

    View Slide

  59. A blossoming ecosystem of saga & process managers
    CADENCE
    Baker

    View Slide

  60. Why not ... persisting commands?
    š Maybe Synchronous
    š Request and Response Style
    š Sender/Receiver Exchange
    š Probably Transient
    š Asynchronous by Nature
    š Fire and Forget Style
    š Publish/Subscribe Exchange
    š Probably Persistent
    Command Event
    Or Asynchronous!
    Like Fire and Listen?
    Like Publish and
    Promise to Subscribe?
    @martinschimak

    View Slide

  61. Don‘t underestimate state managing business logic...
    Payment
    retrieved
    Payment
    service
    Seconds to weeks
    Payment
    retrieval
    canceled
    Timeout
    Retry
    Version
    Compensate
    Parallelise
    Retrieve
    payment
    @martinschimak
    Domain
    Command
    Domain
    Event

    View Slide

  62. Looking behind a „long-running“ service
    Retrieve
    payment
    Payment
    retrieved
    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
    retrieved
    Mark
    payment
    canceled
    Payment
    failed
    Credit
    amount to
    account
    Whenever
    payment is
    canceled
    Mark
    payment
    received
    Payment
    retrieved

    View Slide

  63. Credit amount
    back to account
    Withdraw
    amount from cust.
    account
    Charge amount
    by credit card
    I want that kind of reactive business process execution
    Charge amount
    by credit card
    Credit amount
    back to account
    Update credit card
    details
    Check customer
    account balance
    Payment
    requested
    Depending
    on account
    balance
    Charge
    credit card
    Withdraw
    amount from
    account
    Credit card
    charged
    Whenever
    credit card
    is charged
    Mark
    payment
    received
    Payment
    received
    Amount
    Withdrawn
    Depending
    on the
    amount
    Mark
    payment
    received
    Payment
    received
    Mark paym.
    partly
    covered
    Payment
    partly
    covered
    Whenever
    payment
    p. covered
    Charge
    credit card
    Credit card
    failed
    Whenever
    credit card
    failed
    Update
    credit card
    details
    Credit card
    details
    updated
    Whenever
    card details
    are updated
    Charge
    credit card
    After two
    weeks
    Mark
    payment
    canceled
    Payment
    canceled
    Whenever
    payment is
    canceled
    Credit
    amount to
    account
    Amount
    credited
    Every two
    days
    Remind
    customer
    Customer
    reminded
    Withdraw
    amount from cust.
    account

    View Slide

  64. I want autonomous services - respecting boundaries
    Order service
    Payment service
    Retrieve
    payment
    Payment
    retrieved
    Payment
    failed
    Retrieve
    payment

    View Slide

  65. I want „composition transparent“ commanding
    Order service
    Retrieve
    payment
    Atomic or
    composite
    execution

    View Slide

  66. I want flexible and local technology decisions
    Order service
    Payment service
    Retrieve
    payment
    Payment
    retrieved
    Payment
    failed
    Retrieve
    payment
    Your local implementation reacting to events and commands

    View Slide

  67. medium.com/plexiti @martinschimak
    Thank you!

    View Slide