Towards Modelling Processes

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

Use heuristics

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

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

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


the artefact prescribes the execution process

orderingreceipt

receiving & putaway

negotiationinsurance contract

claim



analysis

tracking

feedback

invoice drafting


implicit internal policy

invoice drafting


explicit policy

invoice drafting


evolving policy

invoice drafting


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