Domain-driven Design: Concepts and Challenges

Slide 1

Slide 1 text

Domain-driven Design: Concepts and Challenges Eberhard Wolff Head of Architecture https://swaglab.rocks/ https://ewolff.com/

Slide 2

Slide 2 text

Domain-driven Design

Slide 3

Slide 3 text

DDD Domain-driven Design •Software should provide business value. •Software should support business processes. •Typical changes are to business logic. •Therefore: Let the domain drive the design! •Actually a great name!

Slide 4

Slide 4 text

Is This a Great Architecture? Data Fetching Service Business Logic Data Service Write Workflow Service UI Aggregation Service API Gateway

Slide 5

Slide 5 text

What is Even the Domain? Data Fetching Service Business Logic Data Service Write Workflow Service UI Aggregation Service API Gateway Technology decisions matter, of course!

Slide 6

Slide 6 text

How Much Technology Do We Need? •Domain Prototyping •No technology at the start •Easy to iterate •Introduce technologies when you really need them …based on more information

Slide 7

Slide 7 text

Domain Prototyping https://software-architektur.tv/2022/09/16/folge134.html

Slide 8

Slide 8 text

Advice: Domain-driven Design •Benefit: More business value and therefore more success •Challenge: Actually focus on the domain not technology! •Advice: Let the domain drive the design!

Slide 9

Slide 9 text

Core Domain

Slide 10

Slide 10 text

Core Domain •Not all parts will have the same quality •Set priorities •Define a Core Domain •The motivation for the project •Differentiates us •Invest effort into it

Slide 11

Slide 11 text

Generic Subdomains •No specialized knowledge •Still essential to the functioning of the system •Not part of the motivation of the project

Slide 12

Slide 12 text

Order Process Invoicing Process Core Domain? Shipping

Slide 13

Slide 13 text

Core Domain? •Unique selling proposition: Reliable shipment on time •Core domain: shipping •Generic subdomains: e.g. bookkeeping but also invoicing and order processing

Slide 14

Slide 14 text

Advice: Core Domain •Benefit: Set the priorities right •Challenge: Depends on business strategy •Advice: Define core domains and generic / supporting subdomains if at all possible.

Slide 15

Slide 15 text

Business Strategy

Slide 16

Slide 16 text

Core Domain? •Let the domain drive the design! •Core domain is not a technical decision!

Slide 17

Slide 17 text

Business Strategy What is goal of this project? How does that benefit the customer? Move to the cloud! What is the purpose of the project?

Slide 18

Slide 18 text

Asking for the Business Strategy •Can provide a huge improvement. •“We now build something that is actually useful for the business.” •Might not be your concern •The project might not really have business value. •The company might not really have a business strategy.

Slide 19

Slide 19 text

Advice: Business Strategy •Benefit: Huge potential for optimization •Challenge: Is the business strategy your concern? •Advice: Try to understand the business strategy •Advice: Understand your role

Slide 20

Slide 20 text

Bounded Context

Slide 21

Slide 21 text

Bounded Context • Usually handled by one team. • Module • Example: Order process, delivery process Bounds Model i.e. Code Ubiquitous Language

Slide 22

Slide 22 text

Order Process Invoicing Process Bounded Context Example Invoicing VAT Shipping Tracking Delivery Accept order Shopping Cart

Slide 23

Slide 23 text

Order Process Invoicing Process Bounded Context Example: Data Customer e.g. billing address Product e.g. price Shipping Customer e.g. shipping address Product e.g. size Product e.g. marketing information Customer e.g. product preferences

Slide 24

Slide 24 text

Public Information Changeable Internals Module

Slide 25

Slide 25 text

Interfaces Code / systems Bounded Context

Slide 26

Slide 26 text

BUILD MODULES BY FUNCTIONALITY NOT DATA!

Slide 27

Slide 27 text

Seriously: BUILD MODULES BY FUNCTIONALITY NOT DATA!

Slide 28

Slide 28 text

Order Process Invoicing Process Bounded Context vs Data Systems Customer e.g. billing address Shipping Customer e.g. shipping address Customer e.g. product preferences Customer Relationship Management Knows everthing about customers

Slide 29

Slide 29 text

Bounded Context vs Data Systems •Reality: Some systems collect all data about specific business entities. •Probably not possible to remove them. •So: need to compromise

Slide 30

Slide 30 text

https://software-architektur.tv/2022/11/18/folge143.html

Slide 31

Slide 31 text

Advice: Bounded Context •Benefit: Great coarse-grained modules •Challenge: Consider functionality first – then data •Challenge: Legacy •Advice: Try to only consider domain aspects in your design sessions.

Slide 32

Slide 32 text

Tactical Design

Slide 33

Slide 33 text

Tactical Design •Object-oriented concepts •Make a lot of sense to build good object-oriented systems!

Slide 34

Slide 34 text

Tactical Design Entity Value Object Aggregate Factory Repository Service Domain Event

Slide 35

Slide 35 text

Advice: Tactical Design •Benefit: Great guideline for object-oriented business systems •Challenge: Used to be misinterpreted as core of DDD •Challenge: Doesn’t assure at all that the domain drives the design! •Advice: Use but focus on the domain!

Slide 36

Slide 36 text

Strategic Design

Slide 37

Slide 37 text

Upstream / Downstream Delivery Order So: delivery team depends on order team to be successful. Delivery need order data.

Slide 38

Slide 38 text

Upstream / Downstream Delivery Order Upstream / downstream is an inevitable result of the split into bounded context.

Slide 39

Slide 39 text

Upstream / Downstream Delivery Order Delivery = Core Domain Core Domain depends on order. What now?

Slide 40

Slide 40 text

Customer / Supplier •Factor downstream priorities (customer) into planning of upstream team (supplier)! •Negotiate and budget tasks!

Slide 41

Slide 41 text

Customer / Supplier Priorities Customer Delivery Supplier Order Negotiate and budget tasks

Slide 42

Slide 42 text

Conformist •Conformist follows the upstream team •No model translation •No veto right •Maybe order is an unchangeable legacy system?

Slide 43

Slide 43 text

Conformist Follows Conformist Delivery Order

Slide 44

Slide 44 text

https://software-architektur.tv/2021/08/27/folge72.html

Slide 45

Slide 45 text

Two git-Repos: How can you distinguish Customer / Supplier and Conformist? Or is information missing?

Slide 46

Slide 46 text

Development Organization Domain / User Software

Slide 47

Slide 47 text

Development Organization Domain / User Software Conformist vs Customer / Supplier

Slide 48

Slide 48 text

Can you set up a Customer / Supplier relationship?

Slide 49

Slide 49 text

Customer / Supplier •Customer / supplier is about who does what. •Probably not what an architect decides.

Slide 50

Slide 50 text

Setting Up Customer / Supplier Customer Supplier

Slide 51

Slide 51 text

Customer / Supplier in Practise We need this feature ASAP! It takes 3 months, and we can’t start until in 6 months. Should take a few days? Customer Supplier It takes 3 months, and we can’t start until in 6 months. Escalate It takes 3 months, and we can’t start until in 6 months.

Slide 52

Slide 52 text

Customer / Supplier •Managers can set up a customer / supplier relationship. •In real life, teams can circumvent or fight such rules.

Slide 53

Slide 53 text

Is this Customer / Supplier? Getting some coffee? Sure! Our bike trip yesterday was great! Oh yes! Listen, I really need your help for our new feature… At the end, he and his team got the help they needed…

Slide 54

Slide 54 text

Strategic Design Challenge: Not easy to implement.

Slide 55

Slide 55 text

https://software-architektur.tv/ tags.html#Domain-driven%20Design

Slide 56

Slide 56 text

Advice: Strategic Design •Benefit: Reach business goal despite dependencies •Benefit: Foundation for self-organization •Challenge: Hard to set up •Advice: Be explicit about the interaction between teams!

Slide 57

Slide 57 text

Socio-technical Systems

Slide 58

Slide 58 text

Development Organization Domain / User Software

Slide 59

Slide 59 text

Development Organization Domain / User Software All of them change!

Slide 60

Slide 60 text

Development Organization Domain / User Software Influences

Slide 61

Slide 61 text

Development Organization Domain / User Software ? ? ? Are you looking for a deterministic, easy to follow set of rules for this?

Slide 62

Slide 62 text

Development Organization Domain / User Software ? ? ? Try it out and see what happens. Sorry.

Slide 63

Slide 63 text

Advice: Socio-technical Systems •Benefit: Better model to think about what we do •Benefit: Socio-technical systems behave very different (complex) from software •Advice: Be aware of what you intuitively know and do.

Slide 64

Slide 64 text

Collaborative Modeling

Slide 65

Slide 65 text

What is Event Storming? •Workshop format to understand complex domains •Introduced by Alberto Brandolini •https://leanpub.com/ introducing_eventstorming •http://ziobrando.blogspot.de/2013/11/ introducing-event-storming.html

Slide 66

Slide 66 text

Development Organisation Domain / User Software Collaborative Modeling

Slide 67

Slide 67 text

Other Type of Collaborative Modeling •Domain Storytelling •Context Mapping •Business Model Canvas •Bounded Context Canvas •…

Slide 68

Slide 68 text

https://software-architektur.tv/2020/09/10/folge017.html

Slide 69

Slide 69 text

https://software-architektur.tv/2020/10/09/folge021.html

Slide 70

Slide 70 text

Advice: Collaborative Modeling •Benefit: Technique to understand the domain •Benefit: Facilitate collaboration •Challenge: Focus on artefact and process instead of collaboration •Challenge: Get the right people •Advice: Important: collaboration about the domain

Slide 71

Slide 71 text

Conclusion

Slide 72

Slide 72 text

What Matters To Me… Core Domain Bounded Context Business Strategy Tactical Design Strategic Design Socio- technical Systems Collaborative Modelling

Slide 73

Slide 73 text

Conclusion •Let the domain drive the design – not the technology! •Business strategy: Huge potential – but your call? •Bounded context: Modules by functionality •Tactical design: Great object-oriented design – but not necessarily DDD •Strategic design: How to implement? •Socio-technical system: No easy recipe •Collaborative modeling: Facilitate collaboration

Slide 74

Slide 74 text

No content

Slide 75

Slide 75 text

60-Minuten-Consulting •Online •kostenlos https://swaglab.rocks/60-min-consulting/

Slide 76

Slide 76 text

Send email to [email protected] Slides + Sample Microservices Book DE / EN + Sample Practical Microservices DE/EN + Sample of Continuous Delivery Book DE Powered by Amazon Lambda & Microservices EMail address logged for 14 days, wrong addressed emails handled manually