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/
3. None

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

46. None

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/