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/

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