Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Domain-driven Design: A Complete Example

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.

Eberhard Wolff

May 14, 2024
Tweet

More Decks by Eberhard Wolff

Other Decks in Technology

Transcript

  1. Why This Talk? •Domain-driven Design provides lots of tools. •Which

    are really useful? •How can you combine them?
  2. Note •This might look like a waterfall. •It is about

    different levels of abstractions. •Work in iterations! •Change the level of abstraction!
  3. Why Event Storming? Domain Experts Understand the domain Software Engineers

    Structure knowledge to become software How does domain knowledge become software?
  4. Why Event Storming? Domain Experts Don’t know formal methods Software

    Engineers Don’t know the domain How does domain knowledge become software?
  5. What is Event Storming? •Event in the past •At least

    noun + verb •Verb in past tense •Write event on orange sticky Order accepted
  6. Phase: Identify Pivotal Events •Afterwards the world is different Order

    accepted Parcel left warehouse Swimlane Invoicing Swimlane Delivery
  7. Event Storming: Benefits •Low-tech: easy to understand for domain experts

    •People can work in parallel. •Social structures become obvious.
  8. 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.
  9. 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
  10. 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.
  11. Invoicing Process Bounded Context Example Customer who pays the bill

    Delivery Customer who the products are sent to
  12. 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
  13. 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
  14. 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
  15. 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!
  16. 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
  17. Core Domain •Core domain = motivation for the project •Reduce

    the complexity of the model •Focus on maintainability of this part of the system
  18. 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
  19. 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
  20. Team Topologies Order Processing Kubernetes / CI Team Delivery Optimization

    Invoicing Delivery XaaS Architecture Collaboration Facilitating XaaS
  21. Tactical Design Entity Value Object Domain Event Identity: a person

    Value: 2€, 2m Something has happened. Matters to domain experts
  22. 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
  23. Tactical Design Entity Value Object Aggregate Factory Repository Service Domain

    Event Logic doesn‘t fit in Entities / Aggregates
  24. 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.
  25. Example: Delivery Bounded Context Parcel <<Entity>> Adress <<ValueObject>> Customer <<Aggregate>>

    Delivery Factory Delivery Repository ScheduleDelivery <<Service>> DeliveryScheduled <<Event>> Delivery <<Aggregate>>
  26. 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
  27. Design-Level Event Storming •Helps to understand the domain on the

    necessary level of detail •But no easy mapping to tactical domain-driven design
  28. 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
  29. Event Sourcing •Store events that lead to a specific state

    •Might also store state (optional) •System of record: State or events
  30. 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
  31. 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?
  32. Command Queue Command Command Command Command Handler Query Handler Command

    Store Database Read Invoice Payment Read Replica? Create Invoice! CQRS
  33. 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
  34. 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?
  35. 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
  36. 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
  37. 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
  38. 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 Slides