DDD Berlin 2017: Tackling Complex Event Flows

Domain-Driven Design Meetup, Berlin, Germany

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“?
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
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