Towards Modelling Processes@mathiasverraes
Mathias Verraes verraes.net
@mathiasverraes
Independent Software Consultant
Student of Systems Meddler of Models Labourer of Legacy
Domain-Driven Design workshops verraes.net/workshops
Domain-Driven Design has evolved a lot
in +10 years
this talk is about
things processes
the grand dichotomy
Great models are
╳ an accurate representation of reality ✓ useful abstractions ✓ solve problems
Being Behaving Becoming
Inspired by ”Rethinking Systems Analysis and Design” — Gerald M. Weinberg
Being How it is structured
Morphology
Behaving How it reacts to inputs Repeatable, reversible
Becoming How it changes into something else
Evolution
structural modelling
focus on artefacts
“As a shopper, in order to buy stuff Given I have a product X with price EUR100
When I …”
“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 …”
pseudo-behavioural
imposes a structural model
“As a shopper, in order to buy stuff Given the shop owner has priced a product X at EUR100
When I …”
“Teachers have multiple courses, each with multiple modules.
Students have multiple courses.”
“Courses are only visible when their status is Approved”
What changes? Why does it change?
Under what circumstances? Who changes it?
How often does it change?
What are the consequences of that change?
Behaving: “Only committee members can approve courses”
Becoming: “Modules are added and removed”
What happens to students who already completed some of the modules that are now obsolete?
time
event sourcing
E E E E E E
A
E = domain event, A = artefact
event storming
EInvoice was paid
time
EC
C = command
Pay for invoice Invoice was paid
time
EC
B = business rule
BPay for invoice Invoice was paid
EC B
Invoice was paid
Invoice was partially paidPay for invoice
Paid amount < Invoice amount Paid amount = Invoice amount
E
C BInvoice was paid
Invoice was partially paid
Paid amount < Invoice amount Paid amount = Invoice amount Paid amount > Invoice amount
Invoice was overpaid
E
C B
= end of lifecycle
Invoice was paid
E
C B
= depends on
payment amountPay for invoice
C BE
E
invoice amount
Invoice was created
C BEC
ECreate invoice
C BEC
E C B
E
All paid amounts < Invoice amount All paid amounts = Invoice amount All paid amounts > Invoice amount
C BEC
E C B
E
E
Invoice was paidInvoice was partially paid
the primitives of our model
artefacts
relations
+ foo() behaviour
timeknowledge
constraints history
intentions branches
processes
And more: actors, queries, …
going further…
actors queries
immediate consistency eventual consistency
aggregates
“Neither a static view nor a dynamic view
can be the whole view.”
Gerald M. Weinberg — Rethinking Systems Analysis and Design
E E E E
A
E E E E
process process
E E E E E E E E
collaborative construction executionartefact
process process
E E E E E E E E
becoming being behaving
invoice drafting
invoice documentinvoicing process
invoice drafting
invoice documentinvoicing process
the artefact prescribes the execution process
orderingreceipt
receiving & putaway
negotiationinsurance contract
claim
collaborative construction executionartefact
collaborative construction executionartefact
analysis
tracking
feedback
invoice drafting
invoice documentinvoicing process
implicit internal policy
invoice drafting
invoice documentinvoicing process
explicit policy
invoice drafting
invoice documentinvoicing process
evolving policy
invoice drafting
invoice documentinvoicing process
evolving policy
configurable policies per tenant
orderingreceipt
receiving & putaway
product changes
negotiationinsurance contract
claim
internal policy
implementation suggestions
Processes with:
Immediately consistent rules => aggregates
Eventually consistent rules => process managers
1 2 3 4
policy changes
Versioning
2
E E EB B
1 2 3 4
2 2
E E E
1 2 3 4
policy changes
Specification
B B
E E E
1 2 3 4
policy changes
Specification
B B
auditing
E E E
1 2 3 4
policy changes
Strategy
B B
E E E
1 2 3 4
policy changes
Running process affected by policy changes
B B
complex business problems require a
temporal model
“The only reason
for time is so that
everything doesn’t happen
at once.”
Albert Einstein
@mathiasverraes verraes.net
dddeurope.com Brussels, January 2016