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.

Transcript

1. Domain-driven Design: Concepts and Challenges Eberhard Wolff Head of Architecture https://swaglab.rocks/ https://ewolff.com/
2. Domain-driven Design
3. 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!
4. Is This a Great Architecture? Data Fetching Service Business Logic Data Service Write Workflow Service UI Aggregation Service API Gateway
5. 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!
6. 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
7. Domain Prototyping https://software-architektur.tv/2022/09/16/folge134.html
8. 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!
9. Core Domain
10. 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
11. Generic Subdomains •No specialized knowledge •Still essential to the functioning of the system •Not part of the motivation of the project
12. Order Process Invoicing Process Core Domain? Shipping
13. Core Domain? •Unique selling proposition: Reliable shipment on time •Core domain: shipping •Generic subdomains: e.g. bookkeeping but also invoicing and order processing
14. 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.
15. Business Strategy
16. Core Domain? •Let the domain drive the design! •Core domain is not a technical decision!
17. 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?
18. 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.
19. 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
20. Bounded Context
21. Bounded Context • Usually handled by one team. • Module • Example: Order process, delivery process Bounds Model i.e. Code Ubiquitous Language
22. Order Process Invoicing Process Bounded Context Example Invoicing VAT Shipping Tracking Delivery Accept order Shopping Cart
23. 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
24. Public Information Changeable Internals Module
25. Interfaces Code / systems Bounded Context
26. BUILD MODULES BY FUNCTIONALITY NOT DATA!
27. Seriously: BUILD MODULES BY FUNCTIONALITY NOT DATA!
28. 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
29. 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
30. https://software-architektur.tv/2022/11/18/folge143.html
31. 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.
32. Tactical Design
33. Tactical Design •Object-oriented concepts •Make a lot of sense to build good object-oriented systems!
34. Tactical Design Entity Value Object Aggregate Factory Repository Service Domain Event
35. 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!
36. Strategic Design
37. Upstream / Downstream Delivery Order So: delivery team depends on order team to be successful. Delivery need order data.
38. Upstream / Downstream Delivery Order Upstream / downstream is an inevitable result of the split into bounded context.
39. Upstream / Downstream Delivery Order Delivery = Core Domain Core Domain depends on order. What now?
40. Customer / Supplier •Factor downstream priorities (customer) into planning of upstream team (supplier)! •Negotiate and budget tasks!
41. Customer / Supplier Priorities Customer Delivery Supplier Order Negotiate and budget tasks
42. Conformist •Conformist follows the upstream team •No model translation •No veto right •Maybe order is an unchangeable legacy system?
43. Conformist Follows Conformist Delivery Order
44. https://software-architektur.tv/2021/08/27/folge72.html
45. Two git-Repos: How can you distinguish Customer / Supplier and Conformist? Or is information missing?
46. Development Organization Domain / User Software
47. Development Organization Domain / User Software Conformist vs Customer / Supplier
48. Can you set up a Customer / Supplier relationship?
49. Customer / Supplier •Customer / supplier is about who does what. •Probably not what an architect decides.
50. Setting Up Customer / Supplier Customer Supplier
51. 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.
52. Customer / Supplier •Managers can set up a customer / supplier relationship. •In real life, teams can circumvent or fight such rules.
53. 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…
54. Strategic Design Challenge: Not easy to implement.
55. https://software-architektur.tv/ tags.html#Domain-driven%20Design
56. 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!
57. Socio-technical Systems
58. Development Organization Domain / User Software
59. Development Organization Domain / User Software All of them change!
60. Development Organization Domain / User Software Influences
61. Development Organization Domain / User Software ? ? ? Are you looking for a deterministic, easy to follow set of rules for this?
62. Development Organization Domain / User Software ? ? ? Try it out and see what happens. Sorry.
63. 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.
64. Collaborative Modeling
65. 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
66. Development Organisation Domain / User Software Collaborative Modeling
67. Other Type of Collaborative Modeling •Domain Storytelling •Context Mapping •Business Model Canvas •Bounded Context Canvas •…
68. https://software-architektur.tv/2020/09/10/folge017.html
69. https://software-architektur.tv/2020/10/09/folge021.html
70. 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
71. Conclusion
72. What Matters To Me… Core Domain Bounded Context Business Strategy Tactical Design Strategic Design Socio- technical Systems Collaborative Modelling
73. 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
75. 60-Minuten-Consulting •Online •kostenlos https://swaglab.rocks/60-min-consulting/
76. Send email to javaland2024@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