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

Domain-driven Design: Concepts and Challenges

Domain-driven Design: Concepts and Challenges

Domain-driven Design (DDD) encompasses various techniques such as strategic DDD, tactical DDD, and collaborative modeling. This presentation provides an overview of the DDD universe, not only introducing the different concepts but also highlighting their respective pros and cons. It also points out common pitfalls and suggests ways to avoid them.

Eberhard Wolff

April 10, 2024

More Decks by Eberhard Wolff

Other Decks in Technology


  1. 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!
  2. Is This a Great Architecture? Data Fetching Service Business Logic

    Data Service Write Workflow Service UI Aggregation Service API Gateway
  3. 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!
  4. 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
  5. 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!
  6. 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
  7. Generic Subdomains •No specialized knowledge •Still essential to the functioning

    of the system •Not part of the motivation of the project
  8. Core Domain? •Unique selling proposition: Reliable shipment on time •Core

    domain: shipping •Generic subdomains: e.g. bookkeeping but also invoicing and order processing
  9. 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.
  10. 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?
  11. 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.
  12. 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
  13. Bounded Context • Usually handled by one team. • Module

    • Example: Order process, delivery process Bounds Model i.e. Code Ubiquitous Language
  14. 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
  15. 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
  16. 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
  17. 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.
  18. 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!
  19. Upstream / Downstream Delivery Order So: delivery team depends on

    order team to be successful. Delivery need order data.
  20. Upstream / Downstream Delivery Order Upstream / downstream is an

    inevitable result of the split into bounded context.
  21. Customer / Supplier •Factor downstream priorities (customer) into planning of

    upstream team (supplier)! •Negotiate and budget tasks!
  22. Conformist •Conformist follows the upstream team •No model translation •No

    veto right •Maybe order is an unchangeable legacy system?
  23. Customer / Supplier •Customer / supplier is about who does

    what. •Probably not what an architect decides.
  24. 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.
  25. Customer / Supplier •Managers can set up a customer /

    supplier relationship. •In real life, teams can circumvent or fight such rules.
  26. 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…
  27. 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!
  28. Development Organization Domain / User Software ? ? ? Are

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

    it out and see what happens. Sorry.
  30. 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.
  31. 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
  32. 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
  33. What Matters To Me… Core Domain Bounded Context Business Strategy

    Tactical Design Strategic Design Socio- technical Systems Collaborative Modelling
  34. 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
  35. 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