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

WJAX Munich 2017: Break your event chains!

WJAX Munich 2017: Break your event chains!

2999fab21d182294fad0b2cc590fd54d?s=128

Martin Schimak

November 08, 2017
Tweet

Transcript

  1. Break your event chains! W-JAX, November 8th, 2017, Munich martin.schimak@plexiti.com

    With thoughts from http://flowing.io @martinschimak | @berndruecker
  2. 3 common hypotheses we check today… 1. Events decrease coupling!

    2. Central control should be avoided! 3. Workflow engines are painful!
  3. None
  4. Simplified example: a 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. Basic idea of dedicated, autonomous (micro-) services Checkout Payment Inventory

    Shipment Dedicated Application Processes Dedicated Persistence Backends Dedicated Development Teams
  8. Events decrease coupling!

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

    blinks green if we can ship the item within 24 hours!“ Request Response
  10. 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
  11. 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
  12. Events can decrease coupling!* *e.g. when used to generate read

    models or to extract cross-cutting aspects
  13. 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
  14. 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
  15. 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
  16. Events can increase coupling* *e.g. complex peer-to-peer event chains

  17. Commands can decrease coupling, too!* *e.g. when used to avoid

    complex peer-to-peer event chains
  18. Are you Event- or Command-Oriented?

  19. Central control should be avoided!

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

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

    dumb pipes!” Martin Fowler
  22. 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?
  23. 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.
  24. 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!“
  25. 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.
  26. Be skeptical about central control!* *e.g. when used as ESB-like

    „smart pipes“or when „god services“ heavily interact with dumb endpoints
  27. But don‘t give up any form of „central“ control!* *e.g.

    by missing to extract important business capabilities which are better dealt with by dedicated, „smart“ services
  28. Do you like or dislike central control? Berlin Munich

  29. Do you like or dislike central control? Brussels Berlin Munich

    @martinschimak J
  30. Workflow engines are painful!

  31. Workflow and BPM

  32. … and death by properties panel The story of BPM:

    Shiny vendors promised zero-code … proprietary, alien like tools …
  33. 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. * Domain-Driven Design, by Eric Evans
  34. When reaching out for DDD, do not violate the bounded

    contexts! Order Inventory Payment
  35. Workflow can be painful!* *e.g. when advertised as „zero-coding“ or

    when violating „bounded contexts“
  36. Persist state with Entity, Actor, … State machine or workflow

    engine DIY Order Credit Card Payment Payment received But then: how to implement long- running services?
  37. State machines or workflow engines CADENCE Baker

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

    Handling of time & timeouts Retry Visibility & Reporting Versioning Compensation Message correlation & deduplication Performance & scalability
  39. 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
  40. Do you need a timeout?

  41. Do you need a compensation? *

  42. Focus on long-running behaviour - requiring state

  43. Specifying and testing long-running behaviour

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

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

    Amount = 30)
  46. Living documentation for long-running behaviour

  47. Workflows live inside service boundaries

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

    Events, Domain Services, etc … + the flow Workflow Engine Payment Application Domain
  49. Lightweight workflow is great! *e.g. developing and testing long-running service

    behaviour, solving hard developer problems, running decentralized
  50. Do you like or dislike workflow?

  51. Don‘t use formal notations for domain exploration.

  52. Include people with accessible methods one can learn on the

    go.
  53. Consider workflow engines and state machines to code complex event

    flows
  54. Need some code?

  55. Need some code? Inventory Payment Order Shipping Checkout Monitor https://github.com/flowing/flowing-retail/

    Human Tasks
  56. None
  57. 1. Events decrease coupling? Sometimes! e.g. for read-models and cross-cutting

    concerns, but: be careful to introduce complex peer-to-peer event chains – consider commands 2. Central control needs to be avoided? Sometimes! e.g. ESB smartness, god services, but: 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
  58. Thank you!

  59. Code online: https://github.com/flowing Slides & Blog: https://plexiti.com With thoughts from

    http://flowing.io @berndruecker | @martinschimak https://www.infoq.com /articles/microservice- event-choreographies
  60. 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/ Images licensed from Shutterstock no attribution required