Domain-driven Design: A Complete Example

What does it actually mean to do Domain-driven Design (DDD)? This talk will walk you through a complete example and show you, how the different techniques like event storming, strategic design, and tactical design work together to support building applications. That way, attendees can see how to start with DDD with a simple yet complete approach.

Transcript

1. Domain-driven Design: A Complete Example Eberhard Wolff Head of Architecture https://swaglab.rocks/ https://ewolff.com/
2. Why This Talk? •Domain-driven Design provides lots of tools. •Which are really useful? •How can you combine them?
3. Note •This might look like a waterfall. •It is about different levels of abstractions. •Work in iterations! •Change the level of abstraction!
4. Event Storming
5. Why Event Storming? Domain Experts Understand the domain Software Engineers Structure knowledge to become software How does domain knowledge become software?
6. Why Event Storming? Domain Experts Don’t know formal methods Software Engineers Don’t know the domain How does domain knowledge become software?
7. Why Event Storming? Domain Experts Software Engineers Model
8. What is Event Storming? •Event in the past •At least noun + verb •Verb in past tense •Write event on orange sticky Order accepted
9. Phase: Chaotic Exploration •Create as many events as possible
10. Phase: Enforce the timeline
11. Phase: Enforce the timeline
12. Phase: Identify Swim Lanes •Parallel activities Swimlane Invoicing Swimlane Delivery
13. Phase: Identify Pivotal Events •Afterwards the world is different Order accepted Parcel left warehouse Swimlane Invoicing Swimlane Delivery
14. Event Storming: Benefits •Low-tech: easy to understand for domain experts •People can work in parallel. •Social structures become obvious.
15. Event Storming: Challenge •Get the right people •Actual users might not have the vision and context. •Managers might not understand problems in day-to- day work. •Everyone will only understand a part of the logic.
16. Event Storming: Result •Common understanding of the domain •A model of the domain …that must be tweaked before it can be implemented •Roles and collaboration in the project become obvious
17. Event Storming: Alternatives •Domain Story Telling: Process-oriented •Context Mapping: List contexts
18. https://software-architektur.tv/2020/10/09/folge021.html
19. https://software-architektur.tv/2022/03/11/folge112.html
20. https://software-architektur.tv/2022/05/20/folge120.html
21. Bounded Context
22. Why Bounded Context? •Coarse-grained split of the domain •A scope that might be assigned to a team •A team might work on multiple bounded contexts …but a bounded context should belong to one team.
23. Bounded Context Bounds Model i.e. Code Ubiquitous Language
24. Ubiquituous Language Database Code Software Engineers Domain Experts
25. Invoicing Process Bounded Context Example Customer who pays the bill Delivery Customer who the products are sent to
26. Parcel left warehouse Identify Candidates for Bounded Contexts •Areas between swim lanes and pivotal events are good candidates for Bounded Contexts Swimlane Delivery Order accepted Swimlane Invoicing
27. Identify Candidates for Bounded Contexts •Areas between swim lanes and pivotal events are good candidates for Bounded Contexts Invoicing Delivery Process Order Processing
28. Identify Candidates for Bounded Contexts •Only Candidates: Still design needed! •Reimbursements handled by invoicing? •Return handled by delivery process? Invoicing Delivery Process Order Processing
29. Bounded Context: Benefits •Structures domain logic •Request probably local to one bounded context •Changes probably local to one bounded context •i.e. a great architecture!
30. Bounded Context: Challenges •Legacy systems have different models. •Most people have an ad-hoc way to structure systems •Mind shift: Focus in domain logic •Mind shift: Functionality not data
31. Bounded Context: Results •Bounded Context = model for business functionality •Small, loosely coupled models / modules •Changes probably contained to one bounded context
32. https://software-architektur.tv/2024/06/14/episode220.html
33. Core Domain
34. Why Core Domain? •Understand the focus
35. Core Domain •Core domain = motivation for the project •Reduce the complexity of the model •Focus on maintainability of this part of the system
36. What is the Core Domain? •We delivery quickly and reliably •So: core domain = delivery process •Rest: generic subdomain …or supporting subdomain Invoicing Delivery Process Order Processing
37. Core Domain: Result •Clear focus •Better understanding of the domain
38. Strategic Design
39. Why Strategic Design? •Somehow teams need to collaborate •Core Domain should be supported by other domains. •No way to ensure the success of the Core Domains just with architecture. •So: need to prioritize core domain on the organizational level.
40. What Is Strategic Design? •Patterns that deal with collaboration •Customer / supplier: Supplier team supports customer team •Conformist: Conformist teams follows the other teams. •Customer / supplier and conformist are opposites.
41. Challenge •My experience: Hard to adapt •Too complicated •Not intuitive? •Only covers teams that work on Bounded Contexts
42. Not Strategic Design but Team Topologies
43. Why Team Topologies? •Somehow teams need to collaborate •Not too complex •Intuitive (?) •Covers more “fracture planes” then just Bounded Contexts e.g. location •Covers more team types than development teams
44. Team Topologies Stream-aligned team Platform team Enabling team Complicated Subsystem team XaaS Collaboration Facilitating XaaS
45. Team Topologies Order Processing Kubernetes / CI Team Delivery Optimization Invoicing Delivery XaaS Architecture Collaboration Facilitating XaaS
46. Team Topologies: Result •Team setup defined •Collaborations defined
47. Team Topologies: Challenges •Magnets i.e. a goal
48. https://software-architektur.tv/2024/04/18/folge213.html
49. https://software-architektur.tv/2024/09/16/episode230.html
50. The Problem with Org Charts
51. Example Platform Team(s) Stream-aligned Team Stream-aligned Team Stream-aligned Team
52. Example •Shall we introduce platform team(s)? •Some common functionalities •Might make sense
53. Example •Toxic environment •Problems are not communicated. •Punishment if problems are communicated •Mistrust
54. Example •Can’t trust the platform team •Platform team won’t make problems transparent •So: Stream-aligned team might not reach goals •But stream-aligned team will be blamed •So: Rather build platform yourself
55. The Problem with Org Charts •Humans don’t necessarily work according to org chart •I.e. you need to solve people problems.
56. Tactical Design
57. Why Tactical Design? •Object-oriented concepts •Make a lot of sense to build good object-oriented systems!
58. Tactical Design Entity Value Object Domain Event Identity: a person Value: 2€, 2m Something has happened. Matters to domain experts
59. Tactical Design Entity Value Object Aggregate Factory Repository Domain Event Consists of Entities and Value Objects Aggregate Root ensures consistency Illusion of a collection of aggregates Creates complex value objects and aggregates
60. Tactical Design Entity Value Object Aggregate Factory Repository Service Domain Event Logic doesn‘t fit in Entities / Aggregates
61. Alternative: Functional Programming •Side-effect free functional core •i.e. no entities, aggregates etc •Side-effects separated
62. https://software-architektur.tv/2023/10/20/folge186.html
63. Alternatives for Less Complex Systems •Transaction script: handles a single request from the presentation incl. database code. •Table model: Single instance handles business logic for all rows in a database table or view.
64. Example: Delivery Bounded Context Parcel <<Entity>> Adress <<ValueObject>> Customer <<Aggregate>> Delivery Factory Delivery Repository ScheduleDelivery <<Service>> DeliveryScheduled <<Event>> Delivery <<Aggregate>>
65. https://software-architektur.tv/2024/05/03/folge214.html
66. Framework? •POJO (Plain Old Java Objects) might be enough •https://xmolecules.org/ supports DDD concepts •https://odrotbohm.de/2020/03/Implementing-DDD- Building-Blocks-in-Java/ describes the idea
67. https://software-architektur.tv/2024/05/31/episode219.html
68. Framework? •Tactical patterns define dependencies •E.g. Services might use Aggregates •Might use architecture management tools to enforce dependencies •https://software-architektur.tv/ tags.html#Architecture%20Management
69. Design Level Event Storming
70. Design-Level Event Storming Actor Command System Domain Event External System Policy Command Read Model UI
71. Design-Level Event Storming •Helps to understand the domain on the necessary level of detail •But no easy mapping to tactical domain-driven design
72. Design-Level Event Storming Actor Command System Domain Event External System Policy Command Read Model UI Aggregate Aggregate, Service Aggregate, Service Aggregate, Service Domain Event
73. Event Sourcing
74. Event Sourcing •Store events that lead to a specific state •Might also store state (optional) •System of record: State or events
75. Interface Calls, messages, … Event Store Order Cancelled 42 Order Accepted 23 Order Accepted 42 Order 42 Order 23 Order Delivered 23 Order 23 State Order 42
76. State Events Calculate State on Demand State+ Events Event Sourcing
77. Event Sourcing Example Event Store Delivery loaded 42 Delivery picked up 42 Delivery scheduled 42 Delivery delivered 42 Delivery acknowledged 42 Can you model delivery without an event store? Why calculate the state of a delivery based on the events and not store the state?
78. CQRS
79. CQRS •Command Query Responsibility Separation •E.g. separate read and write
80. Command Queue Command Command Command Command Handler Query Handler Command Store Database Read Invoice Payment Read Replica? Create Invoice! CQRS
81. Command Queue Command Command Command Command Handler Query Handler Command Store Snapshot Read Invoice Create Invoice! Payment Event Sourcing Might make sense for e.g. statistics CQRS
82. Command Queue Command Command Command Command Handler Query Handler Command Store Snapshot Read Invoice Create Invoice! Payment Event Sourcing Might make sense for e.g. statistics CQRS Can you model statistics differently? Statistics is probably a different bounded context. Why would you use CQRS for the rest?
83. https://software-architektur.tv/2022/04/22/folge116.html
84. Layers
85. Layers •Actual pattern in the original DDD book. •Separate logic •To isolate logic in one place •To make the system easier to understand •DDD does not cover patterns for e.g. UI Persistence Logic UI
86. Hexagonal •Business logic exports ports (interfaces) •Adapters implement ports •Logic isolated and easy to understand •Better testability Business Logic Persistence Business Event Notification Admin Database adapter EMail adapter Admin UI UI
87. https://software-architektur.tv/2024/05/29/episode218.html Ports and Adapters
88. Conclusion
89. Conclusion Big Picture Event Storming Bounded Context Core Domain Strategic Design? Team Topologies More details Event Sourcing? CQRS? Layers? Hexagonal? Design-level Event Storming Tactical Design