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
   

   View Slide

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/
   

   View Slide

3. View Slide

4. Simplified example:
   dash button
   Photo by 0xF2, available under Creative Commons BY-ND 2.0
   license. https://www.flickr.com/photos/0xf2/29873149904/
   

   View Slide

5. Three steps…
   

   View Slide

6. Who is involved?
   Checkout
   Payment
   Inventory
   Shipment
   

   View Slide

7. „Events decrease coupling“?
   

   View Slide

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
   

   View Slide

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
   

   View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

14. „Central control is bad“?
    

    View Slide

15. Checkout
    Payment
    Inventory
    Shipment
    Order
    Order
    placed
    Payment
    received
    Good
    fetched
    Good
    shipped
    Smart ESB-like middleware
    

    View Slide

16. Checkout
    Payment
    Inventory
    Shipment
    Order
    „Dumb“ messaging
    „Smart endpoints and
    dumb pipes!”
    Martin Fowler
    

    View Slide

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?
    

    View Slide

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.
    

    View Slide

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

    View Slide

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.
    

    View Slide

21. Some things in life
    take time
    

    View Slide

22. Persist thing with
    Entity, Actor, …
    State machine or
    workflow engine
    DIY
    Order
    Credit
    Card
    Payment
    Payment
    received
    How to
    implement long-
    running services?
    

    View Slide

23. „Workflow engines are painful“?
    

    View Slide

24. State machines
    or workflow
    engines
    CADENCE
    Baker
    

    View Slide

25. Workflow engines solve some hard developer problems
    Monitoring &
    Operations
    Handling of time &
    timeouts
    Retry
    Visibility &
    Reporting
    Versioning
    Compensation
    Message correlation &
    deduplication
    Performance &
    scalability
    

    View Slide

26. Leaving the aggregate scope?
    

    View Slide

27. Workflow engines solve some hard developer problems
    Monitoring &
    Operations
    Handling of time &
    timeouts
    Retry
    Visibility &
    Reporting
    Versioning
    Compensation
    Message correlation &
    deduplication
    Performance &
    scalability
    

    View Slide

28. Workflow
    and
    BPM #&?!
    

    View Slide

29. Live hacking
    

    View Slide

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
    

    View Slide

31. Do you need a timeout?
    

    View Slide

32. Do you need a compensation? *
    

    View Slide

33. More complex flows - transparent and directly executable
    

    View Slide

34. Specifying and testing long-running behaviour
    

    View Slide

35. A visual test report for example #1 (Balance = 50, Amount = 70)
    

    View Slide

36. A visual test report for example #3 (Balance = 50, Amount = 30)
    

    View Slide

37. The binding strategy uses the step only when required
    

    View Slide

38. Living documentation for long-running behaviour
    

    View Slide

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.
    

    View Slide

40. Workflows live inside service boundaries
    

    View Slide

41. Explicit flows help separate domain and infrastructure
    Infrastructure
    Aggregates,
    Domain Events,
    Domain Services,
    etc …
    + the flow
    Workflow
    Engine
    Payment
    Application
    Domain
    

    View Slide

42. Operational visibility in monitoring
    

    View Slide

43. Focus today:
    executable software
    (not domain exploration)
    

    View Slide

44. Example
    Inventory
    Payment
    Order Shipping
    Checkout Monitor
    https://github.com/flowing/flowing-retail/
    Human
    Tasks
    H2 H2
    

    View Slide

45. Live hacking
    

    View Slide

46. View Slide

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
    

    View Slide

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
    

    View Slide

49. Thank you!
    

    View Slide

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
    

    View Slide

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/
    

    View Slide