Upgrade to Pro — share decks privately, control downloads, hide ads and more …

On to choreography 2.0!

On to choreography 2.0!

@martinschimak -> May 29th, 2019 -> µCon London

Martin Schimak

May 29, 2019
Tweet

More Decks by Martin Schimak

Other Decks in Programming

Transcript

  1. On to choreography 2.0!
    May 29th, 2019 > London > µCon
    @martinschimak

    View full-size slide

  2. "Everything fails all the time”
    -- Werner Vogels, CTO Amazon (since 2005)
    @martinschimak

    View full-size slide

  3. plexiti.com
    @martinschimak

    View full-size slide

  4. Vodafone, Liongate & WDW in Berlin 2018

    View full-size slide

  5. Event-driven architecture is NOT about technology

    View full-size slide

  6. Eric Evans, 2004
    Transactions & Asynchrony
    Boundaries & Autonomy
    Language & Context
    and much more

    View full-size slide

  7. 2004 2006 2008 2018
    2010 2012 2014 2016
    ?
    @martinschimak
    DDD is NOT a book

    View full-size slide

  8. Distributed
    Transactions?
    Missing and
    Duplicates?
    Naïve Eventual
    Consistency?
    Overly Central
    Controllers?
    Temporal
    Coupling?
    Sea of
    Events?
    Sharing
    Everything?
    Unidirectional
    Event Chains?
    Overly Vertical
    Decomposition?
    Central
    Reactors?
    Implicit
    Flows?

    View full-size slide

  9. Hardware
    account
    #123
    Book 10£
    for a new
    mouse
    Acc. #123
    increased
    by 10£
    Intention
    Outcome
    Actor
    Behavior
    Always!
    Bookkeeping system
    Example 1: Simple Profit
    and Loss Accounting
    @martinschimak

    View full-size slide

  10. Book 10£
    for a new
    mouse
    Hardware
    account
    #123
    Acc. #123
    increased
    by 10£ Consistency Boundary
    Cash
    account
    #654
    Example 2: Double
    Entry Accounting
    Intention
    Outcome
    Actor
    Behavior
    Acc. #654
    decreased
    by 10£
    Provided
    balance
    > = 0
    Nothing
    changed
    or
    Accounting
    Service
    @martinschimak

    View full-size slide

  11. Potentially
    dangerous
    pattern
    Book 10£
    for a new
    mouse
    Hardware
    account
    #123
    Acc. #123
    increased
    by 10£
    Cash
    account
    #654
    Example 3: Double
    Entry Accounting
    Intention
    Outcome
    Actor
    Behavior
    Acc. #654
    decreased
    by 10£
    Always!
    Provided
    balance
    > = 0
    Nothing
    changed
    or
    Consistency
    Boundary
    Accounting
    Service
    Network
    Boundary

    View full-size slide

  12. ”Entities and Activities”

    View full-size slide

  13. Intention
    Actor
    Book 10£
    for a new
    mouse
    Hardware
    account
    #123
    Consistency
    Boundary
    Entity & its activities
    @martinschimak

    View full-size slide

  14. Intention
    Outcome
    Actor
    Book 10£
    for a new
    mouse
    Hardware
    account
    #123
    Consistency
    Boundary
    Cash
    account
    #654
    Acc. #123
    increased
    by 10£
    Acc. #654
    decreased
    by 10£
    Eventual
    Consistency
    Async after
    persistence
    @martinschimak

    View full-size slide

  15. Events are safely recorded historical facts
    Amount
    credited
    {
    "name":"AmountCredited",
    "id":{ … },
    "fact":{
    "amount":10

    }
    }
    @martinschimak

    View full-size slide

  16. Hardware
    account
    #123
    Aggregate
    Boundary
    Acc. #123
    increased
    by 10£
    Persisting the (last) state
    When persisting the structural state
    an event can be a transactional “by-
    product” of persisting a new state!
    The aggregate consistency is
    e.g. protected by transactions
    and optimistic locking
    @martinschimak

    View full-size slide

  17. Hardware
    account
    #123
    Aggregate
    Boundary
    Acc. #123
    increased
    by 10£
    Persisting (all) the change
    The aggregate consistency is
    e.g. protected by append only
    logs guaranteeing unique ids
    With Event Sourcing events are the
    only persistent “source of truth”, state
    is dynamically derived in memory
    Acc. #123
    increased
    by 10£
    Acc. #123
    increased
    by 10£
    @martinschimak

    View full-size slide

  18. Distributed
    Transactions?
    Missing and
    Duplicates?
    Naïve Eventual
    Consistency?
    Overly Central
    Controllers?
    Temporal
    Coupling?
    Sea of
    Events?
    Sharing
    Everything?
    Unidirectional
    Event Chains?
    Overly Vertical
    Decomposition?
    Central
    Reactors?
    Missing and
    Duplicates?
    Naïve Eventual
    Consistency?
    Overly Central
    Controllers?
    Temporal
    Coupling?
    Sea of
    Events?
    Sharing
    Everything?
    Unidirectional
    Event Chains?
    Overly Vertical
    Decomposition?
    Central
    Reactors?
    Eventually
    Consistent
    eactions
    Implicit
    Flows?

    View full-size slide

  19. Intention
    Outcome
    Actor
    Book 10£
    for a new
    mouse
    Hardware
    account
    #123
    Cash
    account
    #654
    Acc. #123
    increased
    by 10£
    Acc. #654
    decreased
    by 10£
    Leo
    Actor
    Eventual
    Consistency
    @martinschimak

    View full-size slide

  20. Intention
    Outcome
    Actor
    Book 10£
    for a new
    mouse
    Hardware
    account
    #123
    Cash
    account
    #654
    Acc. #123
    increase
    requested
    Acc. #654
    decreased
    by 10£
    Leo
    Actor
    Eventual
    Consistency
    Acc. #123
    increased
    by 10£
    @martinschimak

    View full-size slide

  21. Intention
    Outcome
    Actor
    Book 10£
    for a new
    mouse
    Hardware
    account
    #123
    Cash
    account
    #654
    Acc. #123
    increase
    requested
    Acc. #654
    decrease
    rejected
    Leo
    Actor
    Eventual
    Consistency
    Acc. #123
    increase
    rejected
    @martinschimak

    View full-size slide

  22. ”Fine-grained workflow with
    entities as the participants”

    View full-size slide

  23. Missing and
    Duplicates?
    Naïve Eventual
    Consistency?
    Overly Central
    Controllers?
    Temporal
    Coupling?
    Sea of
    Events?
    Sharing
    Everything?
    Unidirectional
    Event Chains?
    Overly Vertical
    Decomposition?
    Central
    Reactors?
    Eventually
    Consistent
    eactions
    Missing and
    Duplicates?
    Overly Central
    Controllers?
    Temporal
    Coupling?
    Sea of
    Events?
    Sharing
    Everything?
    Unidirectional
    Event Chains?
    Overly Vertical
    Decomposition?
    Central
    Reactors?
    Eventually
    Consistent
    eactions
    Event Driven
    Workflows
    Implicit
    Flows?

    View full-size slide

  24. Intention
    Actor
    Book 10£
    for a new
    mouse
    Hardware
    account
    #123
    Cash
    account
    #654
    Book 10£
    for a new
    mouse
    Sync. within
    orig. request
    Network
    Boundary
    Consistency
    Boundary
    Example 3: Double
    Entry Accounting
    Potentially
    dangerous
    pattern

    View full-size slide

  25. Intention
    Outcome
    Actor
    Book 10£
    for a new
    mouse
    Hardware
    account
    #123
    Consistency
    Boundary
    Cash
    account
    #654
    Acc. #123
    increased
    by 10£
    Acc. #654
    decreased
    by 10£
    Eventual
    Consistency
    Immutability and Idempotency
    @martinschimak

    View full-size slide

  26. Missing and
    Duplicates?
    Overly Central
    Controllers?
    Temporal
    Coupling?
    Sea of
    Events?
    Sharing
    Everything?
    Unidirectional
    Event Chains?
    Overly Vertical
    Decomposition?
    Central
    Reactors?
    Eventually
    Consistent
    eactions
    Event Driven
    Workflows
    Overly Central
    Controllers?
    Temporal
    Coupling?
    Sea of
    Events?
    Sharing
    Everything?
    Unidirectional
    Event Chains?
    Overly Vertical
    Decomposition?
    Central
    Reactors?
    Eventually
    Consistent
    eactions
    Event Driven
    Workflows
    Immutability and
    Idempotency
    Implicit
    Flows?

    View full-size slide

  27. Temporal coupling with queries Intention
    Actor
    Order Payment Inventory Shipment
    Resource
    Order
    Summary
    Request
    Request
    Request
    Request
    Potentially
    dangerous
    pattern
    Eventual
    Consistency
    Customer
    Customer

    View full-size slide

  28. @martinschimak
    Intention
    Outcome
    Actor
    Resource
    Knowing about change early on
    Order Payment Inventory Shipment
    Order
    Summary
    Eventual
    Consistency
    Customer
    Payment
    retrieved
    Goods
    fetched
    Goods
    shipped

    View full-size slide

  29. Overly Central
    Controllers?
    Temporal
    Coupling?
    Sea of
    Events?
    Sharing
    Everything?
    Unidirectional
    Event Chains?
    Overly Vertical
    Decomposition?
    Central
    Reactors?
    Eventually
    Consistent
    eactions
    Event Driven
    Workflows
    Immutability and
    Idempotency
    Overly Central
    Controllers?
    Sea of
    Events?
    Sharing
    Everything?
    Unidirectional
    Event Chains?
    Overly Vertical
    Decomposition?
    Central
    Reactors?
    Eventually
    Consistent
    eactions
    Event Driven
    Workflows
    Immutability and
    Idempotency
    Knowing
    Change
    Early On
    Implicit
    Flows?

    View full-size slide

  30. Marketing
    Promote
    customer
    Intention
    Payment
    Retrieve
    payment
    Intention
    Intention
    Actor
    Intention
    Fulfillment
    Shipment
    Ship
    goods
    Intention
    Overly central control?
    Potentially
    dangerous
    pattern

    View full-size slide

  31. @martinschimak
    Order
    placed
    Goods
    shipped
    Payment
    retrieved
    More decentral choreography?
    Payment Marketing Shipment
    Order
    Intention
    Actor
    Outcome

    View full-size slide

  32. Intention
    Outcome
    @martinschimak

    View full-size slide

  33. Overly Central
    Controllers?
    Sea of
    Events?
    Sharing
    Everything?
    Unidirectional
    Event Chains?
    Overly Vertical
    Decomposition?
    Central
    Reactors?
    Eventually
    Consistent
    eactions
    Event Driven
    Workflows
    Immutability and
    Idempotency
    Knowing
    Change
    Early On
    Sea of
    Events?
    Sharing
    Everything?
    Unidirectional
    Event Chains?
    Overly Vertical
    Decomposition?
    Central
    Reactors?
    Eventually
    Consistent
    eactions
    Event Driven
    Workflows
    Immutability and
    Idempotency
    Knowing
    Change
    Early On
    More Decentral
    Choreography Implicit
    Flows?

    View full-size slide

  34. Bounded Context
    is not equal to
    Deployment Unit
    @martinschimak

    View full-size slide

  35. Make the context boundary explicit
    Amount
    credited
    {
    "context": "Bookkeeping"
    "name":"AmountCredited",
    "id":{ … },

    }
    @martinschimak
    Delimiting bounded contexts on moving parts ... makes sense both
    1. across multiple fine-grained deployment units <= bounded context
    2. within a coarse-grained monolith deployment unit > = bounded context

    View full-size slide

  36. Sea of
    Events?
    Sharing
    Everything?
    Unidirectional
    Event Chains?
    Overly Vertical
    Decomposition?
    Central
    Reactors?
    Eventually
    Consistent
    eactions
    Event Driven
    Workflows
    Immutability and
    Idempotency
    Knowing
    Change
    Early On
    More Decentral
    Choreography
    Sharing
    Everything?
    Unidirectional
    Event Chains?
    Overly Vertical
    Decomposition?
    Central
    Reactors?
    Eventually
    Consistent
    eactions
    Event Driven
    Workflows
    Immutability and
    Idempotency
    Knowing
    Change
    Early On
    More Decentral
    Choreography
    Explicitly
    Bounded
    Contexts
    Implicit
    Flows?

    View full-size slide

  37. Make the visibility boundary explicit
    @martinschimak
    Amount
    credited
    Internal Event Bus
    if internal
    if public
    Public Event Bus
    Head over to
    Mathias Verraes' blog!

    View full-size slide

  38. For "public" events, consider to share "less"
    @martinschimak
    Account
    closed
    if public
    {
    "context": "BookKeeping"
    "name":"AccountClosed",
    "id":{ … }
    } Public integration events. Consider
    - a dedicated bounded context
    - explicit public event properties
    - coarse-grained summary events
    Public Event Bus
    Head over to
    Mathias Verraes' blog!

    View full-size slide

  39. Sharing
    Everything?
    Unidirectional
    Event Chains?
    Overly Vertical
    Decomposition?
    Central
    Reactors?
    Eventually
    Consistent
    eactions
    Event Driven
    Workflows
    Immutability and
    Idempotency
    Knowing
    Change
    Early On
    More Decentral
    Choreography
    Explicitly
    Bounded
    Contexts
    Unidirectional
    Event Chains?
    Overly Vertical
    Decomposition?
    Central
    Reactors?
    Eventually
    Consistent
    eactions
    Event Driven
    Workflows
    Immutability and
    Idempotency
    Knowing
    Change
    Early On
    More Decentral
    Choreography
    Explicitly
    Bounded
    Contexts
    Explicit
    Visibility
    Layers
    Implicit
    Flows?

    View full-size slide

  40. Auth
    "Central reactors"
    Asynchronous Bus
    Actor
    Outcome
    Account
    closing
    requested
    Account
    closing
    requested
    Account
    closing
    requested
    Account
    closing
    requested
    Account
    closed
    Potentially
    dangerous
    pattern
    Order
    placed
    Payment
    Operation
    authorized
    Payment
    retrieved

    View full-size slide

  41. Payment
    Actor
    Outcome
    Binding to outcomes
    Receiver binds to
    language defined
    by sender!
    Order
    Order
    placed
    Language
    Context of Sender
    @martinschimak

    View full-size slide

  42. Potentially
    dangerous
    pattern
    Asynchronous Bus
    Actor
    "Intentions in disguise"
    Payment
    Outcome
    {
    "context": "Order"
    "name":"PaymentRequired",
    "id":{ … }
    }
    Order
    Payment
    required
    Language
    Context of Sender
    Billable
    Order
    generated
    Order
    placed
    Billable
    Order
    generated

    View full-size slide

  43. Asynchronous Bus
    Actor
    Intention
    Explicit intentions
    Payment
    {
    "context": "Payment"
    "name":"RetrievePayment",
    "id":{ … }

    }
    Language
    Context of
    Receiver
    Order
    Retrieve
    payment
    @martinschimak

    View full-size slide

  44. Asynchronous Bus
    Actor
    Intention
    Promising reactor
    Payment
    Language
    Context of
    Receiver
    Payment
    retrieved
    Outcome
    Retrieve
    payment
    {
    "context": "Payment"
    "name":"PaymentRetrieved",
    "id":{ … }

    }
    Order
    @martinschimak

    View full-size slide

  45. Asynchronous Bus
    Actor
    Intention
    Payment
    Language
    Context of
    Receiver
    Payment
    retrieved
    Outcome
    Retrieve
    payment
    Payment
    failed
    Outcome may
    be a business
    success or failure
    Promising? Yes, some outcome!
    Order
    @martinschimak

    View full-size slide

  46. Asynchronous Bus
    Actor
    Intention
    Payment
    Language
    Context of
    Receiver
    Payment
    retrieved
    Outcome
    Retrieve
    payment
    Payment
    failed
    API modelling a reactive promise
    @martinschimak

    View full-size slide

  47. Asynchronous Bus
    Actor
    Intention
    Payment
    Language
    Context of
    Receiver
    Payment
    retrieved
    Outcome
    Retrieve
    payment
    Payment
    failed
    Explicit intention
    {
    "context":"Payment"
    "type":"Intention",
    "name":"RetrievePayment",
    "id":{ … }

    }
    @martinschimak

    View full-size slide

  48. Asynchronous Bus
    Actor
    Intention
    Payment
    Language
    Context of
    Receiver
    Payment
    retrieved
    Outcome
    Retrieve
    payment
    Payment
    failed
    Explicit outcome
    {
    "context":"Payment"
    "type":"Success",
    "name":"PaymentRetrieved",
    "intention_id": { … }
    "id":{ … }

    }
    @martinschimak

    View full-size slide

  49. Asynchronous Bus
    Payment
    Language
    Context of
    Receiver
    Payment
    retrieved
    Retrieve
    payment
    Payment
    failed
    Full transparency of reactive promises
    o Location
    o Composition
    o Execution Time
    @martinschimak

    View full-size slide

  50. Unidirectional
    Event Chains?
    Overly Vertical
    Decomposition?
    Central
    Reactors?
    Eventually
    Consistent
    eactions
    Event Driven
    Workflows
    Immutability and
    Idempotency
    Knowing
    Change
    Early On
    More Decentral
    Choreography
    Explicitly
    Bounded
    Contexts
    Explicit
    Visibility
    Layers
    Unidirectional
    Event Chains?
    Overly Vertical
    Decomposition?
    Eventually
    Consistent
    eactions
    Event Driven
    Workflows
    Immutability and
    Idempotency
    Knowing
    Change
    Early On
    More Decentral
    Choreography
    Explicitly
    Bounded
    Contexts
    Explicit
    Visibility
    Layers
    Reactive
    Promises
    Implicit
    Flows?

    View full-size slide

  51. @martinschimak
    Order
    placed
    Goods
    shipped
    Payment
    retrieved
    "Implicit, unidirectional event chain"
    Payment Marketing Shipment
    Order
    Actor
    Outcome
    Potentially
    dangerous
    pattern
    "Premium customers
    pay after shipment"
    "Check identity for
    new customers"

    View full-size slide

  52. To insert a link you must open two, to move a link even more

    View full-size slide

  53. Eventual
    consistency
    Binding to intentions
    Order
    Retrieve
    payment
    Sender binds to
    language defined
    by receiver!
    Data Flow
    Direction
    Payment
    Sender Receiver
    Language
    Context of
    Receiver
    Sender decides that a
    payment needs to be
    retrieved!
    depends on
    @martinschimak

    View full-size slide

  54. Payment
    Binding to outcomes
    Receiver binds to
    language defined
    by sender!
    Order
    Order
    placed
    Language
    Context of
    Sender
    Eventual
    consistency
    Data Flow
    Direction
    depends on
    Sender Receiver
    Receiver decides that
    a payment needs to
    be retrieved!
    @martinschimak

    View full-size slide

  55. @martinschimak
    Order
    placed
    Goods
    shipped
    Payment
    retrieved
    Explicit, bidirectional choreography
    Payment Marketing Shipment
    Fulfillment
    "Premium customers
    pay after shipment"
    "Check identity for
    new customers"
    Actor
    Intention
    Outcome
    Retrieve
    payment
    Ship goods

    View full-size slide

  56. Unidirectional
    Event Chains?
    Overly Vertical
    Decomposition?
    Eventually
    Consistent
    eactions
    Event Driven
    Workflows
    Immutability and
    Idempotency
    Knowing
    Change
    Early On
    More Decentral
    Choreography
    Explicitly
    Bounded
    Contexts
    Explicit
    Visibility
    Layers
    Reactive
    Promises
    Overly Vertical
    Decomposition?
    Eventually
    Consistent
    eactions
    Event Driven
    Workflows
    Immutability and
    Idempotency
    Knowing
    Change
    Early On
    More Decentral
    Choreography
    Explicitly
    Bounded
    Contexts
    Explicit
    Visibility
    Layers
    Reactive
    Promises
    Bidirectional
    Choreography
    Implicit
    Flows?

    View full-size slide

  57. Shipment
    Ship
    goods
    Intention
    Intention
    Actor
    Intention
    Payment
    Fulfillment
    Outcome
    Payment
    retrieved
    Retrieve
    payment
    Intention
    Goods
    shipped
    Outcome
    Outcome
    Vertical decomposition: intention + outcomes
    Intentions travel
    vertically downwards
    Outcomes travel
    vertically upwards

    View full-size slide

  58. Shipment
    Ship
    goods
    Intention
    Payment
    Outcome
    Payment
    retrieved
    Retrieve
    payment
    Intention
    Goods
    shipped
    Outcome
    Marketing
    Customer
    promoted
    Intention
    Actor
    Intention
    Outcome
    Horizontal decomposition: mainly outcomes
    Fulfillment
    Mainly outcomes
    travel horizontally
    intentions may travel
    horizontally, e.g. for
    monitoring purposes

    View full-size slide

  59. Balanced decomposition
    Vertical (functional)
    decomposition
    Horizontal (capability)
    decomposition
    may foster too
    much hierarchy
    may foster too
    much implicitness
    A balanced
    decomposition
    leverages both
    options as appropriate

    View full-size slide

  60. Downwards
    & (seldom)
    sidewards
    Upwards
    & (often)
    sidewards
    @martinschimak

    View full-size slide

  61. Overly Vertical
    Decomposition?
    Eventually
    Consistent
    eactions
    Event Driven
    Workflows
    Immutability and
    Idempotency
    Knowing
    Change
    Early On
    More Decentral
    Choreography
    Explicitly
    Bounded
    Contexts
    Explicit
    Visibility
    Layers
    Reactive
    Promises
    Bidirectional
    Choreography
    Eventually
    Consistent
    eactions
    Event Driven
    Workflows
    Immutability and
    Idempotency
    Knowing
    Change
    Early On
    More Decentral
    Choreography
    Explicitly
    Bounded
    Contexts
    Explicit
    Visibility
    Layers
    Reactive
    Promises
    Bidirectional
    Choreography
    Balanced
    Decomposition
    Implicit
    Flows?

    View full-size slide

  62. Business
    Function
    Retrieve
    payment
    Credit card
    charged
    create
    on
    Payment
    Order
    placed
    on
    Charge
    credit card
    create
    Credit Card
    create on
    Payment
    create
    @martinschimak
    Delegation
    of (part of)
    promise
    Execution
    of promise
    Interpretation
    of observation
    on
    Consistency
    Boundaries
    Payment
    retrieved
    on Fulfillment
    Consequence
    of observation
    Vertical
    decomposition

    View full-size slide

  63. Ship goods
    create
    on
    create
    @martinschimak
    Interpretation
    of observation
    Payment
    retrieved
    Fulfillment
    Consequence
    of observation
    Payment
    Promote
    customer
    on Promotions
    Consequence
    of observation
    create
    Horizontal
    decomposition
    Business
    Capability
    Consistency
    Boundaries

    View full-size slide

  64. Aggregate
    Intention
    Outcome
    create
    on
    Aggregate
    Outcome
    on
    Intention
    create
    Aggregate
    create on
    Aggregate
    create
    @martinschimak
    Consequence
    of observation
    Delegation
    of (part of)
    promise
    Execution
    of promise
    Interpretation
    of observation
    on
    Consistency
    Boundaries
    Intention
    on Aggregate
    Consequence
    of observation
    create
    Asynchronous and
    reactive aggregates

    View full-size slide

  65. Outcome Intention
    Aggregate
    create
    @martinschimak
    Execution
    of promise
    A bit often
    discussed
    Aggregates handling
    commands (intention)

    View full-size slide

  66. Aggregate
    Intention
    create
    on
    Aggregate
    Outcome
    on
    Intention
    create
    Aggregate
    create
    @martinschimak
    Consequence
    of observation
    Delegation
    of (part of)
    promise
    Interpretation
    of observation Consistency
    Boundaries
    Intention
    on Aggregate
    Consequence
    of observation
    create
    A bit seldom
    discussed
    Outcome
    on
    Aggregates handling
    sagas and processes

    View full-size slide

  67. ”Fine-grained workflow with
    entities as the participants”

    View full-size slide

  68. Actor Intention
    Consistency
    Boundary
    create
    Outcome
    create
    Intention
    Outcome
    either
    or
    and/or
    How does look like in domain code?
    Behavior
    Behavior
    @martinschimak

    View full-size slide

  69. Fulfillment
    Retrieve
    payment
    Consistency
    Boundary
    create
    Order
    placed
    Consequence
    of observation
    fun handle(outcome: OrderPlaced): Fact {
    // Consequence decision logic here
    return RetrievePayment( /* Constructor params here */ )
    }
    @martinschimak

    View full-size slide

  70. Payment
    Charge
    credit
    card
    Consistency
    Boundary
    create
    Retrieve
    payment
    Delegation
    of (part of)
    promise
    fun handle(intention: RetrievePayment): Fact {
    // Delegation decision logic here
    return ChargeCreditCard( /* Constructor params here */ )
    }
    @martinschimak

    View full-size slide

  71. Credit Card
    Consistency
    Boundary
    Credit
    card
    charged
    create
    Charge
    credit
    card
    Execution
    of promise
    fun handle(intention: ChargeCreditCard): Fact {
    // (in real life execution would still be composite, see later)
    return CreditCardCharged( /* Constructor params here */ )
    }
    @martinschimak

    View full-size slide

  72. Payment
    Consistency
    Boundary
    Payment
    retrieved
    create
    Credit
    card
    charged
    Interpretation
    of observation
    fun handle (success: CreditCardCharged): Fact {
    // Interpretation logic here
    return PaymentRetrieved( /* Constructor params here */ )
    }
    @martinschimak

    View full-size slide

  73. Payment
    Eventually
    Consistent Saga or
    Business Process
    Payment
    retrieved
    create
    Retrieve
    payment
    Composite
    execution
    of promise
    How could look like in domain code?
    Composite
    behavior
    @martinschimak

    View full-size slide

  74. Handlers implementing state transitions
    class Payment {
    fun handle(fact: RetrievePayment): Fact {
    // Business decision logic here
    return ChargeCreditCard( /* Constructor params here */ )
    }
    fun handle(fact: CreditCardCharged): Fact {
    // Business decision logic here
    return PaymentRetrieved( /* Constructor params here */ )
    }
    fun handle(fact: CreditCardFailed): Fact { // … } @martinschimak

    View full-size slide

  75. Make the implicit saga or process flow explicit
    @martinschimak

    View full-size slide

  76. A typed DSL declaring a saga or process flow
    define {
    on message(RetrievePayment::class) …
    execute service {
    create intention(ChargeCreditCard::class) by { … }
    on message(CreditCardCharged::class)
    having "reference" match { paymentId } …
    }
    create success(PaymentRetrieved::class) by {
    PaymentRetrieved(paymentId, covered)
    }
    } @martinschimak

    View full-size slide

  77. Eventually
    Consistent
    eactions
    Event Driven
    Workflows
    Immutability and
    Idempotency
    Knowing
    Change
    Early On
    More Decentral
    Choreography
    Explicitly
    Bounded
    Contexts
    Explicit
    Visibility
    Layers
    Reactive
    Promises
    Bidirectional
    Choreography
    Balanced
    Decomposition
    Explicit
    Flows

    View full-size slide

  78. A typed DSL declaring a saga or process flow
    + Clean, readable code for composite saga/process behavior
    + Options to execute declared state machine with different means
    + Automatic generation of (living, graphical) documentation
    + Everything needed in one place (flow, data, correlation, …)
    MVP coming soon!
    https://github.com/factdriven
    @martinschimak

    View full-size slide

  79. medium.com/plexiti @martinschimak
    Thank you!

    View full-size slide