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

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

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

@martinschimak -> Sep 13th, 2018 -> ExploreDDD Denver

Martin Schimak

September 13, 2018
Tweet

More Decks by Martin Schimak

Other Decks in Programming

Transcript

  1. Event
    Command
    Sep 13th, 2018 -> Denver -> Explore DDD Conference
    Know
    the flow!
    Events, commands and long-running services
    @martinschimak

    View Slide

  2. Apples Oranges
    @martinschimak
    vs

    View Slide

  3. Commands Events
    @martinschimak
    vs
    Retrieve
    payment
    Payment
    retrieved

    View Slide

  4. vs
    Orchestration Choreography
    Long-running
    services

    View Slide

  5. Why?

    View Slide

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

    View Slide

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

    View Slide

  8. Commands and events. And intent.
    „Commands are all about
    intent.
    - Jonas Bonér
    @martinschimak
    Events are intentless.“
    Command
    Retrieve
    payment
    Payment
    retrieved
    Event

    View Slide

  9. Commands and events. Like two sides of a coin.
    Payment
    retrieved
    Payment
    retrieval
    Command Event
    Execution
    Something should happen Something happens Something happened
    Retrieve
    payment
    @martinschimak

    View Slide

  10. Commands and events. Flipping the coin ...
    Payment
    retrieved
    Order
    fulfillment
    process
    Event Execution
    Something happens
    Something happened
    @martinschimak
    Command
    Something should happen
    Fetch
    goods

    View Slide

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

    View Slide

  12. Worker
    Manager
    @martinschimak
    Why?

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  16. 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

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

    View Slide

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

    View Slide

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

    View Slide

  20. Payment Service Credit Card
    Gateway
    @martinschimak

    View Slide

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

    View Slide

  22. plexiti.com
    @martinschimak

    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
    Job Execution
    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
    Command 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
    Command Event
    Order
    fulfillment
    service
    “Long-running”
    service
    “Long-running”
    asynchronous contract
    Hours to weeks
    @martinschimak

    View Slide

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

    View Slide

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

    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. Unhealthy apples vs. fruity and ripe 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. vs
    Apples Oranges
    @martinschimak

    View Slide

  47. Hey DDD! Do you like purely semantical differences? :-)
    š We specified an intended job
    š 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 a relevant change
    š This models everybody’s “state of world”
    š We use past tense to express change
    š Defined and created by emitter bounded
    context and system
    Command Event
    @martinschimak

    View Slide

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

    View Slide

  49. ?
    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

  50. 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
    Command Event(s)
    Events
    Customer Supplier
    Payment Service
    @martinschimak

    View Slide

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

    View Slide

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

    View Slide

  53. Wait. It really depends ... on semantics?
    @martinschimak

    View Slide

  54. 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

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

    View Slide

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

    View Slide

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

    View Slide

  58. @martinschimak

    View Slide

  59. @martinschimak

    View Slide

  60. DangerZone. Experimental. Open
    Thinking. (Apples and Oranges.)

    View Slide

  61. Why not ... persisting commands, too?
    š 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

  62. Payment
    retrieval
    saga
    Payment
    requested
    Order
    fulfillment
    Credit card
    Account
    Withdraw
    amount
    Order placed
    Retrieve
    payment
    Order
    items
    @martinschimak

    View Slide

  63. An eventsourced aggregate ... (1)
    public List process(RetrievePaymentCommand cmd) {
    return EventUtil.events(
    new PaymentRequestedEvent(...)
    );
    }
    @martinschimak

    View Slide

  64. An eventsourced saga pattern ... (2)
    public List process(RetrievePaymentCommand cmd) {
    return EventUtil.events(
    new PaymentRequestedEvent(...),
    new WithdrawAmountCommand(...)
    );
    }
    @martinschimak

    View Slide

  65. Payment
    retrieval
    saga
    Payment
    requested
    Order
    fulfillment
    Credit card
    Account
    Amount
    withdrawn
    Withdraw
    amount
    Payment
    partly
    covered
    Credit Card
    charged
    Charge
    credit card
    Payment
    retrieved
    Order placed
    Retrieve
    payment
    Order
    fulfilled
    Order
    items
    @martinschimak

    View Slide

  66. Payment
    retrieval
    Payment
    requested
    Order
    fulfillment
    Credit card
    Account
    Amount
    withdrawn
    Withdraw
    amount
    Payment
    partly
    covered
    Credit Card
    charged
    Charge
    credit card
    Payment
    retrieved
    Order placed
    Retrieve
    payment
    Order
    fulfilled
    Order
    items
    “Fact”sourced sagas
    know the flow of
    events and commands
    created by itself.
    @martinschimak

    View Slide

  67. “Fact”sourced sagas leverage the “event nature” of commands.
    Command
    Event
    @martinschimak
    creating!
    intent.

    View Slide

  68. Why? Aggregate
    (Worker)
    Process
    Manager
    @martinschimak

    View Slide

  69. Why?
    @martinschimak
    Process
    Manager
    Aggregate

    View Slide

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

    View Slide