DDD Belgium 2017: Events, Flows and Long Running Services

DDD Belgium 2017: Events, Flows and Long Running Services

2999fab21d182294fad0b2cc590fd54d?s=128

Martin Schimak

November 13, 2017
Tweet

Transcript

  1. Events, Flows and Long Running Services Domain-Driven Design Belgium Nov

    13th 2017, Gent, Belgium mail@bernd-ruecker.com martin.schimak@plexiti.com With thoughts from http://flowing.io @berndruecker | @martinschimak
  2. Bernd Rücker Consultant & Dev. Advocate 10+ years workflow Co-founder

    Camunda http://bernd-ruecker.com/ Martin Schimak Developer & Trainer, 10+ years (de-)coding domain knowledge DDDesign, TDD/BDD, EDA http://plexiti.com/ http://flowing.io/
  3. None
  4. Simplified example: dash button Photo by 0xF2, available under Creative

    Commons BY-ND 2.0 license. https://www.flickr.com/photos/0xf2/29873149904/
  5. Three steps…

  6. Who is involved? Checkout Payment Inventory Shipment

  7. „Events decrease coupling“?

  8. Request/Response: temporally coupled services Checkout Payment Inventory Shipment „The button

    blinks green if we can ship the item within 24 hours!“ Request Response
  9. Events: temporal decoupling with read models Checkout Payment Inventory Shipment

    „The button blinks green if we can ship the item within 24 hours!“ Events are facts about what happened (in the past) Good Fetched Good Stored Read Model
  10. Events: extracting or adding cross-cutting aspects Checkout Payment Inventory Shipment

    „Inform the customer about steps s/he is interested in!“ Order placed Payment received Good shipped Notify me when … Order placed Payment received Good fetched Good shipped Customer Mailings Good fetched
  11. Events: peer-to-peer choreographies Checkout Payment Inventory Shipment Order placed Payment

    received Good shipped „When the button is pressed, an order is placed - and fulfilled!“ Good fetched
  12. Events: peer-to-peer choreographies Please fetch the goods before waiting for

    payment Some customers can pay via invoice Checkout Payment Inventory Shipment Good fetched Order placed Payment received Good shipped
  13. Extracting the end-to-end responsibility Order Checkout Payment Inventory Shipment Order

    placed Retrieve payment Commands have an intent about what needs to happen in the future Please fetch the goods before waiting for payment Some customers can pay via invoice Payment received Retrieve payment
  14. „Central control is bad“?

  15. Checkout Payment Inventory Shipment Order Order placed Payment received Good

    fetched Good shipped Smart ESB-like middleware
  16. Checkout Payment Inventory Shipment Order „Dumb“ messaging „Smart endpoints and

    dumb pipes!” Martin Fowler
  17. The danger of god services Checkout Payment Inventory Shipment Order

    „A few smart god services tell anemic CRUD services what to do!” Sam Newman „Central“ order service as bad as central ESB logic?
  18. A god service is created by bad APIs Checkout Payment

    Inventory Shipment Order „Smart endpoints and dumb pipes!” Martin Fowler Checkout Payment Inventory Shipment Smart endpoints take care of a business capability their client does not need to understand.
  19. Ask: who is responsible to deal with problems? Order Credit

    Card Retrieve Payment Expired The client of a dumb service is forced to deal with problems which may actually be none of his business. „If the credit card expired, the customer gets another chance to provide new card details!“
  20. Ask: who is responsible to deal with problems? Order Credit

    Card „If the credit card expired, the customer gets another chance to provide new card details!“ Expired Smart services are potentially long-running. Payment Retrieve Payment Payment received The client of a smart service remains lean.
  21. Some things in life take time

  22. Persist thing with Entity, Actor, … State machine or workflow

    engine DIY Order Credit Card Payment Payment received How to implement long- running services?
  23. „Workflow engines are painful“?

  24. State machines or workflow engines CADENCE Baker

  25. Workflow engines solve some hard developer problems Monitoring & Operations

    Handling of time & timeouts Retry Visibility & Reporting Versioning Compensation Message correlation & deduplication Performance & scalability
  26. Leaving the aggregate scope?

  27. Workflow engines solve some hard developer problems Monitoring & Operations

    Handling of time & timeouts Retry Visibility & Reporting Versioning Compensation Message correlation & deduplication Performance & scalability
  28. Workflow and BPM #&?!

  29. Live hacking

  30. Bpmn.createProcess("order").executable() //... .sendTask().name("Retrieve payment").camundaClass(RetrievePayme .receiveTask().name("Payment received").message("PaymentReceive //... { "name": "retrieve_payment",

    "tasks": [ { "name": "Retrieve Payment", "taskReferenceName": "payment", "type": "SIMPLE", ... Do you prefer coded or graphical DSLs? * BPMN - ISO notation for modeling and executing long-running processes and flows
  31. Do you need a timeout?

  32. Do you need a compensation? *

  33. More complex flows - transparent and directly executable

  34. Specifying and testing long-running behaviour

  35. A visual test report for example #1 (Balance = 50,

    Amount = 70)
  36. A visual test report for example #3 (Balance = 50,

    Amount = 30)
  37. The binding strategy uses the step only when required

  38. Living documentation for long-running behaviour

  39. The DDD idea of ubiquitous language needs boundaries Checkout Payment

    Inventory Shipment Ubiquitous Language Software Experts Domain Experts Useful models capturing an “ubiquitous language” need boundaries.
  40. Workflows live inside service boundaries

  41. Explicit flows help separate domain and infrastructure Infrastructure Aggregates, Domain

    Events, Domain Services, etc … + the flow Workflow Engine Payment Application Domain
  42. Operational visibility in monitoring

  43. Focus today: executable software (not domain exploration)

  44. Example Inventory Payment Order Shipping Checkout Monitor https://github.com/flowing/flowing-retail/ Human Tasks

    H2 H2
  45. Live hacking

  46. None
  47. New kid on the block https://zeebe.io/ Zeebe Broker Your application

    Binary (MsgPack) Support streaming & batching Client Horiziontally scalable Append only log / event sourcing Peer-to-peer cluster
  48. 1. Events decrease coupling? Often! But not always. e.g. events

    decrease coupling when used for read-models and cross-cutting concerns, but: be careful to introduce complex peer-to-peer event chains – consider commands 2. Central control is bad? It can be! Respect the BC! e.g. ESB smartness, god services often violate the odea of bounded contexts, but: don‘t throw out the baby with the bath, important business capabilities need a home 3. Workflow engines are painful? Some of them! e.g. with „zero coding“, when violating bounded contexts, but: lightweight engines enable long-running services, run decentralized, solve hard developer problems
  49. Thank you!

  50. Code online: https://github.com/flowing Slides & Blog: https://bernd-ruecker.com https://plexiti.com With thoughts

    from http://flowing.io @berndruecker | @martinschimak https://www.infoq.com /articles/microservice- event-choreographies
  51. Images licensed from iStock no attribution required All icons licensed

    from Noun Project no attribution required Images licensed under Creative Commons license Photo by 0xF2, available under Creative Commons BY-ND 2.0 license. https://www.flickr.com/photos/0xf2/2987 3149904/