Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Talk at DDD Berlin: Tackling complex event flows

596 views

Published on

Slides from my talk together with Martin Schimak at the DDD meetup Berlin hold on 25th of September 2017 about complex event flows in DDD and microservice architectures. Summary: Think about introducing commands whenever appropriate, understand that this is some kind of orchestration, do it the right way (distributed orchestration), probably use some proper state machine whenever things get long running and embrace a new possibility to leverage ubiquitous language within flows.

Code from the live demo here: https://github.com/flowing/flowing-retail-concept-java. Look at branches step0 -> step2

Published in: Technology
  • Be the first to comment

Talk at DDD Berlin: Tackling complex event flows

  1. 1. Tackling complex event flows Domain-driven design meetup Berlin, 5th september 2017 martin.schimak@plexiti.com bernd.ruecker@camunda.com With thoughts from http://flowing.io @berndruecker | @martinschimak
  2. 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. 3. https://www.flickr.com/photos/12567713@N00/310639290
  4. 4. Microservices Domain-Driven Design Event-Driven & Reactive
  5. 5. Assume we want to build a Dash button
  6. 6. Pay item Ship item Let‘s go! We need three steps… Fetch item
  7. 7. Let‘s do a bit context mapping… Checkout Context Payment Context Inventory Context Shipment Context
  8. 8. An organisation‘s business capabilities … Inventory ShipmentCheckout Payment Business Capabilities Order placed Payment received Goods fetched Goods shipped Business Outputs
  9. 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. 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. 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. 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. 13. Let‘s do a bit more context mapping… Checkout Context Payment Context Inventory Context Shipment Context
  14. 14. Live demo
  15. 15. We should probably add an additional context Order Context Checkout Context Payment Context Inventory Context Shipment Context
  16. 16. We should probably add an additional context Order Context Checkout Context Payment Context Inventory Context Shipment Context
  17. 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. 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. 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. 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. 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. 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. 23. Orchestration vs. Choreography?
  24. 24. Some things in life take time
  25. 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. 26. Most services are potentially long running Inventory Service Shipment Service Order Service Payment Service
  27. 27. How to handle state?
  28. 28. Live demo
  29. 29. • Do event command transformation • Handle state for long running flows • Implement the flow as 1st class citizen of domain logic
  30. 30. Routing slip Persistent thing (Entity, Actor, …) State machine How to implement?
  31. 31. Routing slip Persistent thing (Entity, Actor, …) State machine
  32. 32. State machines solve some hard developer problems Monitoring & Operations Handling of time & timeouts Retry Visibility & Reporting Versioning Compensation Message correlation Performance & scalability
  33. 33. Flow logic is about ubiquitous language Ubiquitous Language Software Experts Domain Experts
  34. 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. 35. Ubiquitous language is about directly executable domain models
  36. 36. Ubiquitous language is about living documentation
  37. 37. Ubiquitous language is about executable specifications
  38. 38. Ubiquitous language could be more about operational visibility 345 67812
  39. 39. Smells like „BPM“?
  40. 40. … and death by properties panel Same story with BPM: Shiny vendors promised zero-code … proprietary, alien like tools …
  41. 41. Let‘s do „flows“ instead of BPM developer friendly composable business inclusion
  42. 42. AT&T
  43. 43. Multiple engines instead of a BPM monolith Payment Order flow engine flow engine Inventory Shipping Payment Order Inventory Shipping BPM
  44. 44. 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
  45. 45. DEFINITELY. Do not violate the bounded contexts! Order Inventory Payment
  46. 46. Distributed flows are managed inside long running services Inventory Service Shipment Service Payment Service Order Service Order Payment
  47. 47. Payment Distributed flows are owned by bounded contexts Order Distributed orchestration
  48. 48. 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?
  49. 49. Architecture Infrastructure Application Domain Engine
  50. 50. The engine? Engine Your application DB Your application engine DB
  51. 51. 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
  52. 52. More realistic demo available InventoryPaymentOrder ShippingShop Monitor https://github.com/flowing/flowing-retail/
  53. 53. Is it web scale? Engine RDMS
  54. 54. 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
  55. 55. Thank you!
  56. 56. https://www.flickr.com/photos/12567713@N00/310639290 Summary
  57. 57. 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

×