DDD Belgium 2017: Events, Flows and Long Running Services

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/
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
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/