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

Know the flow! Events, commands and long-runnin...

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
  2. Events look into the past „An event is something that

    has happened in the past.“ - Greg Young Payment retrieved @martinschimak
  3. Commands look into the future A command specifies something that

    should happen in the future. Retrieve payment @martinschimak
  4. Commands and events. And intent. „Commands are all about intent.

    - Jonas Bonér @martinschimak Events are intentless.“ Command Retrieve payment Payment retrieved Event
  5. 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
  6. Commands and events. Flipping the coin ... Payment retrieved Order

    fulfillment process Event Execution Something happens Something happened @martinschimak Command Something should happen Fetch goods
  7. Events are really simple to grasp ... Goods shipped Order

    placed Goods fetched Payment retrieved ... EventStorming! @martinschimak
  8. Events to separate write and read models ... Order summary

    Payment retrieved Payment UI raises projected onto ... CQRS! @martinschimak
  9. Events to temporally decouple services ... Order summary Payment retrieved

    Payment UI raises projected onto Payment Service Order Service ... CQRS with „foreign“ events! @martinschimak
  10. Events to represent history and state of systems ... Payment

    received Payment Payment received Payment received Payment received Payment retrieved ... Event Sourcing! @martinschimak
  11. Events to enable whole business processes ... ... Event choreographies!

    Payment received Inform customer listened to by Payment Service Notification Service @martinschimak
  12. Item ordered My context of sophisticated fulfillments Energy traded Order

    fulfillment Energy trade execution Coverage extension requested Policy issuance @martinschimak
  13. 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
  14. 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
  15. „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
  16. „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
  17. „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
  18. Order Service Order placed Payment Service Payment retrieved Inventory Service

    Goods fetched Shipment Service Goods shipped The choreography principle @martinschimak
  19. 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
  20. Order Service Order placed Payment Service Payment retrieved Inventory Service

    Goods fetched Shipment Service Goods shipped Choreographies and their implicit process logic ... @martinschimak
  21. 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
  22. 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...
  23. 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
  24. 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
  25. 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
  26. 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
  27. 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
  28. ? ? ? 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
  29. 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
  30. ? Payment Service Why not publish the command? Order Service

    Retrieve payment Payment retrieved Publish @martinschimak
  31. ? Payment Service ... we get location transparency inside a

    context ... Order Service Retrieve payment Payment retrieved Publish Subscribe Financial Services Bounded Context @martinschimak
  32. ? 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!“
  33. 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
  34. 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
  35. ? 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!
  36. ? 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
  37. 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
  38. 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
  39. 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
  40. 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
  41. 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
  42. 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
  43. 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
  44. Payment retrieval saga Payment requested Order fulfillment Credit card Account

    Withdraw amount Order placed Retrieve payment Order items @martinschimak
  45. An eventsourced aggregate ... (1) public List<Event> process(RetrievePaymentCommand cmd) {

    return EventUtil.events( new PaymentRequestedEvent(...) ); } @martinschimak
  46. An eventsourced saga pattern ... (2) public List<Event> process(RetrievePaymentCommand cmd)

    { return EventUtil.events( new PaymentRequestedEvent(...), new WithdrawAmountCommand(...) ); } @martinschimak
  47. 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
  48. 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