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. Bounded Context
18. 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.
19. Bounded Context Bounds Model i.e. Code Ubiquitous Language
20. Ubiquituous Language Database Code Software Engineers Domain Experts
21. Invoicing Process Bounded Context Example Customer who pays the bill Delivery Customer who the products are sent to
22. Parcel left warehouse Identify Candidates for Bounded Contexts •Areas between swim lanes and pivotal events are good candidates for Bounded Contexts •Not all pivotal events separate bounded contexts Swimlane Delivery Order accepted Swimlane Invoicing
23. Parcel left warehouse Identify Candidates for Bounded Contexts •Areas between swim lanes and pivotal events are good candidates for Bounded Contexts •Not all pivotal events separate bounded contexts Swimlane Delivery Order accepted Invoicing Delivery Process Order Processing Swimlane Invoicing
24. Identify Candidates for Bounded Contexts •Reimbursements handled in invoicing? •Return handled in delivery process? •Is the model usable for both? Invoicing Delivery Process Order Processing
25. 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!
26. 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
27. Core Domain
28. Core Domain •Core domain = motivation for the project •Reduce the complexity of the model •Focus on maintainability of this part of the system
29. 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
30. Not Strategic Design but Team Topologies
31. 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
32. Team Topologies Stream-aligned team Platform team Enabling team Complicated Subsystem team XaaS Collaboration Facilitating XaaS
33. Team Topologies Order Processing Kubernetes / CI Team Delivery Optimization Invoicing Delivery XaaS Architecture Collaboration Facilitating XaaS
34. Team Topologies: Challenges •Magnets i.e. a goal
35. https://software-architektur.tv/2024/04/18/folge213.html
36. Finally: Coding!
37. Finally: Coding! (sort of )
38. Tactical Design
39. Why Tactical Design? •Object-oriented concepts •Make a lot of sense to build good object-oriented systems!
40. Tactical Design Entity Value Object Domain Event Identity: a person Value: 2€, 2m Something has happened. Matters to domain experts
41. 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
42. Tactical Design Entity Value Object Aggregate Factory Repository Service Domain Event Logic doesn‘t fit in Entities / Aggregates
43. Alternative: Functional Programming •Side-effect free functional core •i.e. no entities, aggregates etc •Side-effects separated
44. 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.
45. Example: Delivery Bounded Context Parcel <<Entity>> Adress <<ValueObject>> Customer <<Aggregate>> Delivery Factory Delivery Repository ScheduleDelivery <<Service>> DeliveryScheduled <<Event>> Delivery <<Aggregate>>
46. https://software-architektur.tv/2024/05/03/folge214.html
47. 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
48. Framework? •Might use architecture management tools to enforce dependencies •https://software-architektur.tv/ tags.html#Architecture%20Management
49. Design-Level Event Storming Actor Command System Domain Event External System Policy Command Read Model UI
50. Design-Level Event Storming •Helps to understand the domain on the necessary level of detail •But no easy mapping to tactical domain-driven design
51. 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
52. Event Sourcing •Store events that lead to a specific state •Might also store state (optional) •System of record: State or events
53. 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
54. State Events Calculate State on Demand State+ Events Event Sourcing
55. 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?
56. CQRS •Command Query Responsibility Separation •E.g. separate read and write
57. Command Queue Command Command Command Command Handler Query Handler Command Store Database Read Invoice Payment Read Replica? Create Invoice! CQRS
58. 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
59. 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?
60. Layers •Actually pattern in the original DDD book. •Separate logic •To isolate logic in one place •To make the system easier to understand Persistence Logic UI
61. Hexagonal •Business logic exports ports •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
62. Conclusion
63. 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
64. Send email to jcon2024@ewolff.com 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 Slides