Slide 1

Slide 1 text

BPMN DDD Process Automation with Domain-Driven Design © Martin Schimak – plexiti GmbH – All rights reserved

Slide 2

Slide 2 text

This is our automated process! Process starts! Make decision Check HUMAN REJECT! FRAUD_S ERVICE ANTI pattern

Slide 3

Slide 3 text

After five sprints, it finally works! RAUD_S ERVICE Check GET invoice POST negative amount Process ends. REJECT! Yes No ANTI pattern

Slide 4

Slide 4 text

You got it?

Slide 5

Slide 5 text

Eric Evans, 2004

Slide 6

Slide 6 text

2004 2006 2008 2018 2010 2012 2014 2016 ? DDD … is not a book! It only started as a book. 2020

Slide 7

Slide 7 text

Applying DDD to Process Automation …

Slide 8

Slide 8 text

Process Automation "Done Right"

Slide 9

Slide 9 text

No content

Slide 10

Slide 10 text

2) Strategic Design The three pillars of Domain-Driven Design 3) Modeling in Code 1) Collaborative Modeling 1) Collaborative Modeling

Slide 11

Slide 11 text

"Ubiquitous" Language DDD emphasizes the importance of language for modeling executable software.

Slide 12

Slide 12 text

Stop nitpicking about "labeling"! Process starts! Make decision Check HUMAN REJECT! FRAUD_S ERVICE ANTI pattern

Slide 13

Slide 13 text

Healthily obsess with language! Process starts! Make decision Check HUMAN REJECT! FRAUD_S ERVICE DDD Paradigm Invoice dispute raised Determine dispute handling strategy Economic relevance? Low: automatic handling Higher: manual handling Check invoice dispute Approved Approved Rejected Determine fraud potential Partially approved Partially rejected Dispute approved? Determine dispute handling strategy Check invoice dispute Determine fraud potential

Slide 14

Slide 14 text

Healthily obsess with language! DDD Paradigm

Slide 15

Slide 15 text

Think. Together.

Slide 16

Slide 16 text

"Handing over" diagrams. ANTI pattern Analyst Developer Tester

Slide 17

Slide 17 text

In DDD modeling is collaborative DDD emphasizes the importance of developing a shared mental model. DDD Paradigm

Slide 18

Slide 18 text

You need workshop methods which enable everybody in a meeting room to contribute

Slide 19

Slide 19 text

Understand the bigger picture of your domain! EVENTSTORMiNG

Slide 20

Slide 20 text

Events (and more) on a timeline Something business relevant happened! Invoice dispute raised Invoice dispute approved Invoice dispute rejected Time

Slide 21

Slide 21 text

Useful for process automation projects? Invoice dispute raised Invoice dispute approved Invoice dispute rejected Invoice dispute checked Yes! Time

Slide 22

Slide 22 text

EVENTSTORMiNG Understand the bigger picture of your domain!

Slide 23

Slide 23 text

Easily explore specific domain scenarios! EVENTSTORMiNG

Slide 24

Slide 24 text

Useful for process automation projects? Invoice dispute raised Invoice dispute approved Invoice dispute rejected Invoice Check Fraud Detection Service Design sophisticated collaboration models with your domain experts Yes!

Slide 25

Slide 25 text

Easily explore specific domain scenarios!

Slide 26

Slide 26 text

storystorming.com

Slide 27

Slide 27 text

2) Strategic Design The three pillars of Domain-Driven Design 3) Modeling in Code 1) Collaborative Modeling 2) Strategic Design

Slide 28

Slide 28 text

Violating responsibility boundaries ANTI pattern Customer Care Fraud Prevention Billing

Slide 29

Slide 29 text

Central orchestration Customer Care Fraud Prevention Billing Invoice Dispute ANTI pattern

Slide 30

Slide 30 text

Subdomains & Bounded Contexts DDD Paradigm Customer Care Invoice Dispute Fraud Prevention Fraud Detection Billing Invoicing Crediting API C/S C/S C/S Internal Customer- Supplier Relationship

Slide 31

Slide 31 text

Invoice Dispute Process (in Customer Care)

Slide 32

Slide 32 text

Fraud Detection Process (in Fraud Prevention)

Slide 33

Slide 33 text

Crediting Process (in Billing)

Slide 34

Slide 34 text

Universal enterprise-wide model Customer Care Fraud Prevention Billing ANTI pattern

Slide 35

Slide 35 text

Defined language boundaries DDD Paradigm Customer Care Fraud Prevention Billing API

Slide 36

Slide 36 text

DDD's "ubiquitous language" is NOT universal

Slide 37

Slide 37 text

Bounded contexts for models DDD Paradigm Customer Care Fraud Prevention Billing API

Slide 38

Slide 38 text

2) Strategic Design The three pillars of Domain-Driven Design 3) Modeling in Code 1) Collaborative Modeling 3) Modeling in Code

Slide 39

Slide 39 text

Search! Close! Jump! Customer Care Fraud Prevention Billing ANTI pattern Process controls other services

Slide 40

Slide 40 text

Process automation IMPLEMENTS non-atomic, asynchronous services

Slide 41

Slide 41 text

Processes implement a service DDD Paradigm Customer Care Fraud Prevention Billing API

Slide 42

Slide 42 text

Intention revealing interfaces DDD Paradigm Billing API

Slide 43

Slide 43 text

Synchronous interfaces Billing Sync API Customer Care What looks like a simple, fast and atomic operation today, can tomorrow turn out to be … ANTI pattern

Slide 44

Slide 44 text

A long-running, async business operation

Slide 45

Slide 45 text

Asynchronous interfaces Billing Async API Customer Care Feed Async APIs will NOT break, if you later need more than just a simple, fast, atomic operation to implement

Slide 46

Slide 46 text

Objects & code inside the process Do not mix domain objects or domain code into your process model • No type safety or code completion! • Editing code in vendor-specific modelers? Nah. • Difficult or even impossible to test :-( • Complex domain objects as JSON ... seriously? process + objects + code Crediting ANTI pattern

Slide 47

Slide 47 text

Processes as aggregates Model the process flow in a visual form 1 DDD Paradigm Invoice Dispute Process Model the domain objects in code 2 Invoice Dispute Root Entity 3 Bind them 1:1 and transition them as an aggregate 1 1 ${root}

Slide 48

Slide 48 text

Chaotic consistency boundaries ANTI pattern Update with an ACID transaction A B

Slide 49

Slide 49 text

Defined consistency boundaries DDD Paradigm Update with an ACID transaction B A Aggregates Strong consistency Eventual consistency

Slide 50

Slide 50 text

BPMN DDD Well-designed processes can be seen as aggregates?

Slide 51

Slide 51 text

Thank you! BPMN DDD Process Automation with Domain-Driven Design © Martin Schimak – plexiti GmbH – All rights reserved