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

DDD Berlin 2017: Tackling Complex Event Flows

DDD Berlin 2017: Tackling Complex Event Flows

Domain-Driven Design Meetup, Berlin, Germany

2999fab21d182294fad0b2cc590fd54d?s=128

Martin Schimak

September 05, 2017
Tweet

Transcript

  1. Tackling complex event flows Domain-Driven Design Meetup Berlin, September 5th

    2017 martin.schimak@plexiti.com bernd.ruecker@camunda.com With thoughts from http://flowing.io @berndruecker | @martinschimak
  2. Bernd Rücker Consultant & Evangelist 10+ years workflow Co-founder Camunda

    http://bernd-ruecker.com/ Martin Schimak Consultant & Trainer 15+ years domain (de-)coding DDDesign, TDD/BDD, EDA http://plexiti.com/ http://flowing.io/
  3. https://www.flickr.com/photos/12567713@N00/310639290

  4. Microservices Domain-Driven Design Event-Driven & Reactive

  5. Assume we want to build a Dash button

  6. Pay item Ship item Let‘s go! We need three steps…

    Fetch item
  7. Let‘s do a bit context mapping… Checkout Context Payment Context

    Inventory Context Shipment Context
  8. An organisation‘s business capabilities … Inventory Shipment Checkout Payment Business

    Capabilities Order placed Payment received Goods fetched Goods shipped Business Outputs
  9. … are delivered by people … and more and more

    software Inventory Service Shipment Service Checkout Service Payment Service Services and Teams Domain Events Order placed Payment received Goods fetched Goods shipped
  10. Eric Evans‘ Bounded Context • An ubiquitous domain language …

    • … lives and survives within boundaries • … which provide context for modeling 2003 Inventory Service Shipment Service Checkout Service Payment Service
  11. Bill Poole‘s discussion of business capabilities “A business capability is

    something that an organization does that contributes in some way towards the overall function performed by the organization” http://bill-poole.blogspot.dk/2008/07/business-capabilities.html Inventory Service Shipment Service Checkout Service Payment Service 2008
  12. Business Capabilities for µServices Autonomy Dan North about microservices: „Software

    that Fits in Your Head“ Inventory Service Shipment Service Checkout Service Payment Service 2015 ff. https://www.infoq.com/presentations/microservices-replaceability-consistency
  13. Let‘s do a bit more context mapping… Checkout Context Payment

    Context Inventory Context Shipment Context
  14. Live demo

  15. We should probably add an additional context Order Context Checkout

    Context Payment Context Inventory Context Shipment Context
  16. We should probably add an additional context Order Context Checkout

    Context Payment Context Inventory Context Shipment Context
  17. An Order Service transforms events to commands. Inventory Service Shipment

    Service Payment Service Order Service Payment received Goods fetched Goods shipped Collect payment
  18. Inventory Service Shipment Service Payment Service Order Service The danger

    with the so called orchestration principle Inventory Service Shipment Service Payment Service Order Service „A few smart god services tell anemic CRUD services what to do!” Sam Newman
  19. Inventory Service Shipment Service Customer Account Service Payment Service Services

    Events Address changed The choreography principle is especially strong in enabling decentral data management
  20. Inventory Service Shipment Service Checkout Service Payment Service But event

    chaining has coupling issues too… Payment received Goods fetched Goods shipped Order placed
  21. Decoupling? Whenever a new client requires payment, the payment context

    has to be touched Whenever the logic of the order fulfillment changes, the payment context might need to be touched Order placed Payment Service Product Subscription confirmed Dash Button installed
  22. Events vs. Commands 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 Service Retrieve payment Payment Service Customer status changed
  23. Orchestration vs. Choreography?

  24. Some things in life take time

  25. A customer can update his expired credit card within two

    weeks before we cancel his order Business requirements „ Distributed systems …the world of distributed systems —  where systems fail in the most spectacular and intricate ways… Jonas Boner „
  26. Most services are potentially long running Inventory Service Shipment Service

    Order Service Payment Service
  27. How to handle state?

  28. Live demo

  29. • Do event command transformation • Handle state for long

    running flows • Implement the flow as 1st class citizen of domain logic
  30. Routing slip Persistent thing (Entity, Actor, …) State machine How

    to implement?
  31. Routing slip Persistent thing (Entity, Actor, …) State machine

  32. State machines solve some hard developer problems Monitoring & Operations

    Handling of time & timeouts Retry Visibility & Reporting Versioning Compensation Message correlation Performance & scalability
  33. Flow logic is about ubiquitous language Ubiquitous Language Software Experts

    Domain Experts
  34. „Foreign“ Contexts Events, Commands, … Own Order Context Domain Code

    Aggregates, Events, Command Logic, … Flow as an implementation of a long-running Command Ubiquitous language is about transparency for domain concepts
  35. Ubiquitous language is about directly executable domain models

  36. Ubiquitous language is about living documentation

  37. Ubiquitous language is about executable specifications

  38. Ubiquitous language could be more about operational visibility 345 678

    12
  39. Smells like „BPM“?

  40. None
  41. … and death by properties panel Same story with BPM:

    Shiny vendors promised zero-code … proprietary, alien like tools …
  42. Let‘s do „flows“ instead of BPM developer friendly composable business

    inclusion
  43. None
  44. AT&T

  45. Multiple engines instead of a BPM monolith Payment Order flow

    engine flow engine Inventory Shipping Payment Order Inventory Shipping BPM
  46. Still remember the danger with monolithic orchestration? Inventory Service Shipment

    Service Payment Service „A few smart god services tell anemic CRUD services what to do!” Sam Newman
  47. DEFINITELY. Do not violate the bounded contexts! Order Inventory Payment

  48. Distributed flows are managed inside long running services Inventory Service

    Shipment Service Payment Service Order Service Order Payment
  49. Payment Distributed flows are owned by bounded contexts Order Distributed

    orchestration
  50. Providing long-running commands allows the context to enforce its boundaries

    Inventory Service Shipment Service Payment Service Order Service Retrieve payment Charge credit card What is our service API?
  51. Architecture Infrastructure Application Domain Engin e

  52. The engine? Engine Your application DB Your application engine DB

  53. Order Order Order Order Architecture Order Engine A Payment Engine

    B Monitor Human Task Management Coarse grained central monitoring Fine grained monitoring & operations (per context) DevOps Tec Ops Biz Ops Central
  54. More realistic demo available Inventory Payment Order Shipping Shop Monitor

    https://github.com/flowing/flowing-retail/
  55. Is it web scale? Engine RDMS

  56. 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
  57. Thank you!

  58. https://www.flickr.com/photos/12567713@N00/310639290 Summary

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

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