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.
Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (20)
Similar to Why Domain-Driven Design Matters
Similar to Why Domain-Driven Design Matters (20)
More from Mathias Verraes
More from Mathias Verraes (12)
Recently uploaded
Recently uploaded (20)
Why Domain-Driven Design Matters
- 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?
- 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.”
- 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.”
- 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.”
- 24. FAST ITERATION LEAN STARTUP VALIDATED LEARNING
- 36. DESIGN PATTERNS
- 37. “DESIGN PATTERNS ARE A GATEWAY DRUG TO DOMAIN- DRIVEN DESIGN”
- 38. SUPPLE DESIGN
- 40. REFACTORING
- 41. BOUNDED CONTEXTS
- 42. DISTILLATION
- 45. MODEL STORMING
- 46. DESIGN MATTER ? DOMAIN-DRIVEN So WHY DOES
- 48. “A LARGE SYSTEM, PRODUCED BY EXPANDING THE DIMENSIONS OF A SMALL SYSTEM, DOES NOT BEHAVE LIKE THE SMALLER SYSTEM” JOHN GALL