Towards Modelling Processes
3 likes1,024 views
The document discusses the evolution of domain-driven design and offers insights into modeling processes, focusing on the concepts of behaving, becoming, and structures within systems. It emphasizes the importance of understanding changes in processes and policies over time, along with the need for temporal models to address complex business problems. The author highlights various modeling concepts such as event sourcing, collaborative construction, and the distinction between immediate and eventual consistency.
Towards Modelling Processes
- 2. Mathias Verraes verraes.net @mathiasverraes Independent Software Consultant Student of Systems Meddler of Models Labourer of Legacy
- 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
- 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 …”
- 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. EC C = command Pay for invoice Invoice was paid time
- 29. EC 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 BE E invoice amount Invoice was created
- 36. C BEC E C B E
- 37. C BEC E C B E All paid amounts < Invoice amount All paid amounts = Invoice amount All paid amounts > Invoice amount
- 38. C BEC E C B E E Invoice was paidInvoice was partially paid
- 39. the primitives of our model
- 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
- 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
- 60. Processes with: Immediately consistent rules => aggregates Eventually consistent rules => process managers
- 61. 1 2 3 4 policy changes Versioning 2 E E EB 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