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

Why Domain-Driven Design Matters

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.

330627d5f564b710721236077903ed60?s=128

Mathias Verraes

May 20, 2014
Tweet

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