Why Domain-Driven Design Matters

Why Domain-Driven Design Matters

In the software industry, the life expectancy of ideas, methodologies, and technologies, is extremely short. And yet, after ten years, Domain-Driven Design is still growing bigger. From it’s original roots in OOP, it has now expanded into Functional Programming, Reactive Programming and Event Sourcing, and architectural styles such as Hexagonal and CQRS. Clearly something about Domain-Driven Design makes it such an appealing choice to build systems for complex domains.

In this session, we’ll discuss what DDD is: from design patterns and modelling techniques, to the more philosophical ideas about how we deal with complexity. We explore why it has made such a profound impact, and how to decide whether it’s right for your project. We’ll have lots of room for open discussion, to make sure all your questions are answered.

--

Mathias Verraes is a recovering music composer turned programmer, consultant, blogger, speaker, and podcaster. He advises companies on how to build enterprise web applications for complex business domains . For some weird reason, he enjoys working on large legacy projects: the kind where there’s half a million lines of spaghetti code, and nobody knows how to get the codebase under control. He’s the founder of the Domain-Driven Design Belgium community. When he’s not working, he’s at home in Kortrijk, Belgium, helping his two sons build crazy Lego train tracks.

Transcript

1. DESIGN MATTERS DOMAIN-DRIVEN WHY
2. Mathias Verraes Student of Systems
   Meddler of Models
   Labourer of Legacy verraes.net mathiasverraes
3. SET OF DESIGN PATTERNS?
4. SET OF DESIGN PATTERNS? METHODOLOGY?
5. SET OF DESIGN PATTERNS? METHODOLOGY? TOTAL APPROACH TO DEALING WITH COMPLEXITY?
6. SET OF DESIGN PATTERNS? METHODOLOGY? TOTAL APPROACH TO DEALING WITH COMPLEXITY? PHILOSOPHY?
7. INFLUENCE ORGANISATION ! ‑ ! SOFTWARE
8. INFLUENCE ORGANISATION ! ‑ SOFTWARE ORGANISATION ! ‑
9. INFLUENCE - ORGANISATION - - SOFTWARE - HARDWARE - - RESPONSIVENESS TO BUGS - - CONTRACTS - THIRD PARTIES - - DEVELOPER HAPPINESS - TOOLS - - TESTS - SKILLS - COMMUNICATION -
10. “IT IS AN AXIOM THAT INFLUENCE IS BOTH A CAUSE AND AN EFFECT. NOTHING IS EVER INFLUENCED IN JUST ONE DIRECTION.”
11. “THE CAUSATION FALLACY: ! EVERY EFFECT HAS A CAUSE AND WE CAN TELL WHICH IS WHICH.”
12. SYSTEMS GENERAL THINKING
13. “EVERYTHING IS A SYSTEM. EVERYTHING IS PART OF A SYSTEM.”
14. SYSTEMS ! Thinking about systems as dynamic, evolving patterns of interaction and feedback.
15. “JUST CALLING IT ‘FEEDBACK’ DOESN'T MEAN THAT IS HAD ACTUALLY FED BACK. IT HASN'T FED BACK UNTIL THE SYSTEM CHANGES COURSE.” JOHN GALL
16. “IGNORING FEEDBACK MERELY MEANS THAT THE SYSTEM WILL EVENTUALLY EXPERIENCE A MASSIVE UNPLEASANT SURPRISE (RATHER THAN A SMALL UNPLEASANT SURPRISE).” JOHN GALL
17. “IT MAY LOOK LIKE A CRISIS, BUT IT'S ONLY THE END OF AN ILLUSION.”
18. “SYSTEMS TEND TO OPPOSE THEIR OWN PROPER FUNCTION.”
19. “SYSTEMS INHERENTLY RESIST CHANGE.”
20. “THE MORE ADAPTED AN ORGANISM IS TO PRESENT CONDITIONS, THE LESS ADAPTABLE IT TENDS TO BE TO UNKNOWN FUTURE CONDITIONS.”
21. “IT'S CALLED ‘SOFTWARE’ FOR A REASON. IT'S SUPPOSED TO BE EASY TO CHANGE.”
22. DESIGN SOFTWARE HAS A SLOW
23. FAST ITERATION LEAN STARTUP AGILE TDD BDD KANBAN
24. FAST ITERATION LEAN STARTUP VALIDATED LEARNING
25. FAST ITERATION AGILE COLLABORATE
26. FAST ITERATION TDD DESIGN SMALL
27. FAST ITERATION BDD COMMUNICATE
28. FAST ITERATION KANBAN IMPROVE CONTINUOUSLY
29. (broad generalisations)
30. DESIGN GOES DEEPER DOMAIN-DRIVEN
31. DOMAIN PROBLEM SPACE DOMAIN MODEL SOLUTION SPACE
32. DOMAIN & DOMAIN MODEL IN SYNC KEEP
33. UBIQUITOUS LANGUAGE
34. DESIGN TACKLES DOMAIN-DRIVEN COMPLEXITY
35. ACCIDENTAL COMPLEXITY ESSENTIAL COMPLEXITY
36. DESIGN PATTERNS
37. “DESIGN PATTERNS ARE A GATEWAY DRUG TO DOMAIN- DRIVEN DESIGN”
38. SUPPLE DESIGN
39. DECLARATIVE DESIGN
40. REFACTORING
41. BOUNDED CONTEXTS
42. DISTILLATION
43. LARGE SCALE STRUCTURE
44. MODELLING WHIRLPOOL
45. MODEL STORMING
46. DESIGN MATTER ? DOMAIN-DRIVEN So WHY DOES
47. INFLUENCE FEEDBACK PATTERNS SYSTEMS COMPLEXITY ITERATIONS WHY CAN’T IT BE SIMPLE?
48. “A LARGE SYSTEM, PRODUCED BY EXPANDING THE DIMENSIONS OF A SMALL SYSTEM, DOES NOT BEHAVE LIKE THE SMALLER SYSTEM” JOHN GALL
49. verraes.net mathiasverraes
50. verraes.net mathiasverraes