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

ExploreDDD Denver 2017: Tackling Complex Event Flows

ExploreDDD Denver 2017: Tackling Complex Event Flows

ExploreDDD 2017, Denver, Colorado, USA

Martin Schimak

September 21, 2017
Tweet

More Decks by Martin Schimak

Other Decks in Programming

Transcript

  1. Tackling complex event flows ExploreDDD – Denver, Colorado, USA –

    Sep 21st 2017 @martinschimak – [email protected] With thoughts from http://flowing.io @berndruecker | @martinschimak
  2. „The button just blinks green and confirms the order if

    we can ship the item within 72 hours!“
  3. Let‘s look into Domain Events <<root entity>> Good - goodId

    - ... <<value object>> Location - coordinates - ... 0..* <<event>> GoodFetched - goodId - ...
  4. Inventory Shipment Checkout Payment Services with decentral data … by

    enabling decentral data management Good shippable within 72 hours!
  5. Inventory Shipment Checkout Payment With choreographies services trigger based on

    events Payment received Good fetched Good shipped Order placed
  6. „Our customer is king. From now on, we fetch the

    items before we collect the money!“ A simple requirement?
  7. Inventory Shipment Checkout Payment Pure event choreographies have some coupling

    issues…. Payment received Good fetched Good shipped Order placed All three event subscriptions have to change – at the same time
  8. Where do we put that kind of „domain logic“? Checkout

    Context Payment Context Inventory Context Shipment Context
  9. Are these the organisation‘s business capabilities? Inventory Shipment Checkout Payment

    Business Capabilities Order placed Payment received Good fetched Good shipped Business Purpose
  10. Or are we missing the organisation‘s core capability? Inventory Shipment

    Checkout Payment Order placed Order Order fulfilled
  11. Let‘s try to add an additional context… Order Context Checkout

    Context Payment Context Inventory Context Shipment Context
  12. … and change the communication patterns, too Order Context Checkout

    Context Payment Context Inventory Context Shipment Context
  13. Does this mean we do not use events anymore? No.

    Inventory Shipment Payment Order Collect payment Checkout Order placed
  14. But the order service translates the event to a command

    Inventory Shipment Payment Order Payment received Collect payment Checkout Order placed
  15. „Our customer is king. From now on, we fetch the

    items before we collect the money!“ A simple requirement? Yes.
  16. The danger with the so called orchestration principle „A few

    smart god services tell anemic CRUD services what to do!” Sam Newman Inventory Service Shipment Service Payment Service Order Service Checkout Service Inventory Service Shipment Service Payment Service Order Service Checkout Service
  17. Carrying out business capabilities takes time Inventory Shipment Checkout Payment

    Order placed Payment received Good fetched Good shipped Order Order fulfilled
  18. A „responsible“ payment service potentially needs a bit longer Payment

    Retrieve payment Payment received Charge credit card Credit card expired Charging currently not possible
  19. „A customer can update his expired credit card within two

    weeks before we cancel his order!“ The story just began… … …
  20. Exposing fine grained APIs pushes requirements into „god clients“ Inventory

    Shipment Payment Order Checkout Charge credit card Credit card expired Charging currently not possible
  21. Exposing APIs along business capabilities keeps clients lean Inventory Shipment

    Payment Order Checkout Retrieve payment Payment received Charge credit card Credit card expired Charging currently not possible
  22. Who is - organisationally - responsible? Conciously decide where to

    do the coupling Command Something has to happen in the future => 1 recipient Event Something has happend in the past => 0..n recipients Order placed Order Retrieve payment Payment
  23. • Do event command transformation • Handle state for long

    running flows • Implement the flow as 1st class citizen of domain logic
  24. Sophisticated state machines solve some hard developer problems Monitoring &

    Operations Handling of time & timeouts Retry Visibility & Reporting Versioning Compensation Message correlation Performance & scalability
  25. Their explicit flow language helps in tackling complex event flows

    Ubiquitous Language Software Experts Domain Experts
  26. The DSL does not have to be graphical… e.g. {

    "name": "encode_and_deploy", "description": "Encodes a file and deploys to CDN", "version": 1, "tasks": [ { "name": "encode", "taskReferenceName": "encode", "type": "SIMPLE", … offers a JSON DSL Bpmn.createExecutableProcess("order") .startEvent() .serviceTask().name("Retrieve payment").camundaClass(RetrievePaymentAdapter.class) .serviceTask().name("Fetch goods").camundaClass(FetchGoodsAdapter.class) .serviceTask().name("Ship goods").camundaClass(ShipGoodsAdapter.class) .endEvent().camundaExecutionListenerClass("end", GoodsShippedAdapter.class) .done(); offers a Java DSL
  27. Flow logic is full of highly relevant domain concepts Ports

    and Adapters Application Domain State machine Payment Store Aggregates, Domain Events, Domain Services, etc … … but also the DSL defining the flow
  28. Using flows correctly does not violate your context boundaries Inventory

    Service Shipment Service Checkout Service Order Service Order Payment Payment Service
  29. Building a dash button – extended demo! for demo simplicity,

    just start all services in single Java VM https://github.com/flowing/flowing-retail/ Inventory Payment Order Shipping Shop Monitor
  30. Code online: https://github.com/flowing Slides & Blogs: https://plexiti.com https://bernd-ruecker.com With thoughts

    from http://flowing.io @berndruecker | @martinschimak https://www.infoq.com /articles/microservice- event-choreographies