Towards Modelling Processes

Towards Modelling Processes

Processes are at the heart of how many businesses operate. The processes are governed by policies, agreed upon with contracts, and guided by documents. In software systems on the other hand, we often bury the processes. There’s a domain model for sure, but it’s all about “things” and “actions”. Let’s explore how Event Sourcing allows us to explicitly model the effects of changes over time.

http://verraes.net/2015/05/towards-modelling-processes/

330627d5f564b710721236077903ed60?s=128

Mathias Verraes

May 22, 2015
Tweet

Transcript

  1. Towards Modelling Processes @mathiasverraes

  2. Mathias Verraes verraes.net @mathiasverraes Independent Software Consultant Student of Systems

    Meddler of Models Labourer of Legacy
  3. Domain-Driven Design workshops verraes.net/workshops

  4. None
  5. Domain-Driven Design has evolved a lot in +10 years

  6. this talk is about things processes the grand dichotomy

  7. Great models are ╳ an accurate representation of reality ✓

    useful abstractions ✓ solve problems
  8. Use heuristics

  9. Being Behaving Becoming Inspired by ”Rethinking Systems Analysis and Design”

    — Gerald M. Weinberg
  10. Being How it is structured Morphology

  11. Behaving How it reacts to inputs Repeatable, reversible

  12. Becoming How it changes into something else Evolution

  13. structural modelling focus on artefacts

  14. “As a shopper, in order to buy stuff Given I

    have a product X with price EUR100 When I …”
  15. “As a shop owner, in order to sell stuff Given

    I have a product X, And that product is priced EUR 100 in the pricing table When I …”
  16. pseudo-behavioural

  17. imposes a structural model

  18. “As a shopper, in order to buy stuff Given the

    shop owner has priced a product X at EUR100 When I …”
  19. “Teachers have multiple courses, each with multiple modules. Students have

    multiple courses.”
  20. “Courses are only visible when their status is Approved”

  21. What changes? Why does it change? Under what circumstances? Who

    changes it? How often does it change? What are the consequences of that change?
  22. Behaving: “Only committee members can approve courses”

  23. Becoming: “Modules are added and removed”

  24. What happens to students who already completed some of the

    modules that are now obsolete?
  25. time event sourcing E E E E E E A

    E = domain event, A = artefact
  26. event storming

  27. event storming E Invoice was paid time

  28. E C C = command Pay for invoice Invoice was

    paid time
  29. E C B = business rule B Pay for invoice

    Invoice was paid
  30. E C B Invoice was paid Invoice was partially paid

    Pay for invoice Paid amount < Invoice amount Paid amount = Invoice amount
  31. E C B Invoice was paid Invoice was partially paid

    Paid amount < Invoice amount Paid amount = Invoice amount Paid amount > Invoice amount Invoice was overpaid
  32. E C B = end of lifecycle Invoice was paid

  33. E C B = depends on payment amount Pay for

    invoice
  34. C B E E invoice amount Invoice was created

  35. C B E C E Create invoice

  36. C B E C E C B E

  37. C B E C E C B E All paid

    amounts < Invoice amount All paid amounts = Invoice amount All paid amounts > Invoice amount
  38. C B E C E C B E E Invoice

    was paid Invoice was partially paid
  39. the primitives of our model

  40. artefacts relations + foo() behaviour

  41. time knowledge constraints history intentions branches processes And more: actors,

    queries, …
  42. going further… actors queries immediate consistency eventual consistency aggregates

  43. “Neither a static view nor a dynamic view can be

    the whole view.” Gerald M. Weinberg — Rethinking Systems Analysis and Design
  44. E E E E A E E E E process

    process
  45. E E E E E E E E collaborative construction

    execution artefact process process
  46. E E E E E E E E becoming being

    behaving
  47. invoice drafting invoice document invoicing process

  48. invoice drafting invoice document invoicing process the artefact prescribes the

    execution process
  49. ordering receipt receiving & putaway

  50. negotiation insurance contract claim

  51. collaborative construction execution artefact

  52. collaborative construction execution artefact analysis tracking feedback

  53. invoice drafting invoice document invoicing process implicit internal policy

  54. invoice drafting invoice document invoicing process explicit policy

  55. invoice drafting invoice document invoicing process evolving policy

  56. invoice drafting invoice document invoicing process evolving policy

  57. configurable policies per tenant ordering receipt receiving & putaway

  58. product changes negotiation insurance contract claim internal policy

  59. implementation suggestions

  60. Processes with: Immediately consistent rules => aggregates Eventually consistent rules

    => process managers
  61. 1 2 3 4 policy changes Versioning 2 E E

    E B B 1 2 3 4 2 2
  62. E E E 1 2 3 4 policy changes Specification

    B B
  63. E E E 1 2 3 4 policy changes Specification

    B B auditing
  64. E E E 1 2 3 4 policy changes Strategy

    B B
  65. E E E 1 2 3 4 policy changes Running

    process affected by policy changes B B
  66. complex business problems require a temporal model

  67. “The only reason for time is so that everything doesn’t

    happen at once.” Albert Einstein
  68. @mathiasverraes verraes.net dddeurope.com Brussels, January 2016