Process Automation with Domain-Driven Design @ Navigate 2021

In this talk I discuss the application of “strategic” and “tactical” patterns and best practices from domain-driven design to software projects for the automation of business processes - with or without the use of workflow engines. I will show that the two different worlds - “DDD” and “Workflow” - which appear to be very different and often look at each other with skepticism - have much more in common than not - but if and only if they are cleverly linked.

Transcript

1. BPMN DDD Process Automation with Domain-Driven Design © Martin Schimak – plexiti GmbH – All rights reserved
2. This is our automated process! Process starts! Make decision Check HUMAN REJECT! FRAUD_S ERVICE ANTI pattern
3. After five sprints, it finally works! RAUD_S ERVICE Check GET invoice POST negative amount Process ends. REJECT! Yes No ANTI pattern
4. You got it?
5. Eric Evans, 2004
6. 2004 2006 2008 2018 2010 2012 2014 2016 ? DDD … is not a book! It only started as a book. 2020
7. Applying DDD to Process Automation …
8. Process Automation "Done Right"
10. 2) Strategic Design The three pillars of Domain-Driven Design 3) Modeling in Code 1) Collaborative Modeling 1) Collaborative Modeling
11. "Ubiquitous" Language DDD emphasizes the importance of language for modeling executable software.
12. Stop nitpicking about "labeling"! Process starts! Make decision Check HUMAN REJECT! FRAUD_S ERVICE ANTI pattern
13. 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
14. Healthily obsess with language! DDD Paradigm
15. Think. Together.
16. "Handing over" diagrams. ANTI pattern Analyst Developer Tester
17. In DDD modeling is collaborative DDD emphasizes the importance of developing a shared mental model. DDD Paradigm
18. You need workshop methods which enable everybody in a meeting room to contribute
19. Understand the bigger picture of your domain! EVENTSTORMiNG
20. Events (and more) on a timeline Something business relevant happened! Invoice dispute raised Invoice dispute approved Invoice dispute rejected Time
21. Useful for process automation projects? Invoice dispute raised Invoice dispute approved Invoice dispute rejected Invoice dispute checked Yes! Time
22. EVENTSTORMiNG Understand the bigger picture of your domain!
23. Easily explore specific domain scenarios! EVENTSTORMiNG
24. 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!
25. Easily explore specific domain scenarios!
26. storystorming.com
27. 2) Strategic Design The three pillars of Domain-Driven Design 3) Modeling in Code 1) Collaborative Modeling 2) Strategic Design
28. Violating responsibility boundaries ANTI pattern Customer Care Fraud Prevention Billing
29. Central orchestration Customer Care Fraud Prevention Billing Invoice Dispute ANTI pattern
30. 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
31. Invoice Dispute Process (in Customer Care)
32. Fraud Detection Process (in Fraud Prevention)
33. Crediting Process (in Billing)
34. Universal enterprise-wide model Customer Care Fraud Prevention Billing ANTI pattern
35. Defined language boundaries DDD Paradigm Customer Care Fraud Prevention Billing API
36. DDD's "ubiquitous language" is NOT universal
37. Bounded contexts for models DDD Paradigm Customer Care Fraud Prevention Billing API
38. 2) Strategic Design The three pillars of Domain-Driven Design 3) Modeling in Code 1) Collaborative Modeling 3) Modeling in Code
39. Search! Close! Jump! Customer Care Fraud Prevention Billing ANTI pattern Process controls other services
40. Process automation IMPLEMENTS non-atomic, asynchronous services
41. Processes implement a service DDD Paradigm Customer Care Fraud Prevention Billing API
42. Intention revealing interfaces DDD Paradigm Billing API
43. 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
44. A long-running, async business operation
45. 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
46. 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
47. 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}
48. Chaotic consistency boundaries ANTI pattern Update with an ACID transaction A B
49. Defined consistency boundaries DDD Paradigm Update with an ACID transaction B A Aggregates Strong consistency Eventual consistency
50. BPMN DDD Well-designed processes can be seen as aggregates?
51. Thank you! BPMN DDD Process Automation with Domain-Driven Design © Martin Schimak – plexiti GmbH – All rights reserved