Why Domain-Driven Design Matters

8,637 views

Published on

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.

Published in: Design, Technology, Business

Why Domain-Driven Design Matters

  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. INFLUENCEORGANISATION! ➡! SOFTWARE
  8. INFLUENCEORGANISATION! ➡ 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

×