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.

Mathias Verraes

May 20, 2014
Tweet

More Decks by Mathias Verraes

Other Decks in Technology

Transcript

  1. DESIGN
    MATTERS
    DOMAIN-DRIVEN
    WHY

    View Slide

  2. Mathias Verraes
    Student of Systems
    Meddler of Models
    Labourer of Legacy
    verraes.net
    mathiasverraes

    View Slide

  3. SET OF DESIGN PATTERNS?

    View Slide

  4. SET OF DESIGN PATTERNS?
    METHODOLOGY?

    View Slide

  5. SET OF DESIGN PATTERNS?
    METHODOLOGY?
    TOTAL APPROACH TO DEALING
    WITH COMPLEXITY?

    View Slide

  6. SET OF DESIGN PATTERNS?
    METHODOLOGY?
    TOTAL APPROACH TO DEALING
    WITH COMPLEXITY?
    PHILOSOPHY?

    View Slide

  7. INFLUENCE
    ORGANISATION
    !

    !
    SOFTWARE

    View Slide

  8. INFLUENCE
    ORGANISATION
    !

    SOFTWARE
    ORGANISATION
    !

    View Slide

  9. INFLUENCE
    - ORGANISATION -
    - SOFTWARE - HARDWARE -
    - RESPONSIVENESS TO BUGS -
    - CONTRACTS - THIRD PARTIES -
    - DEVELOPER HAPPINESS - TOOLS -
    - TESTS - SKILLS - COMMUNICATION -

    View Slide

  10. “IT IS AN AXIOM THAT
    INFLUENCE IS BOTH A
    CAUSE AND AN EFFECT.
    NOTHING IS EVER
    INFLUENCED IN JUST
    ONE DIRECTION.”

    View Slide

  11. “THE CAUSATION
    FALLACY:
    !
    EVERY EFFECT HAS A
    CAUSE AND WE CAN
    TELL WHICH IS WHICH.”

    View Slide

  12. SYSTEMS
    GENERAL
    THINKING

    View Slide

  13. “EVERYTHING IS
    A SYSTEM.
    EVERYTHING IS
    PART OF A
    SYSTEM.”

    View Slide

  14. SYSTEMS
    !
    Thinking about systems as
    dynamic, evolving patterns of
    interaction and feedback.

    View Slide

  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

    View Slide

  16. “IGNORING FEEDBACK
    MERELY MEANS THAT THE
    SYSTEM WILL EVENTUALLY
    EXPERIENCE A MASSIVE
    UNPLEASANT SURPRISE
    (RATHER THAN A SMALL
    UNPLEASANT SURPRISE).”
    JOHN GALL

    View Slide

  17. “IT MAY LOOK
    LIKE A CRISIS,
    BUT IT'S ONLY
    THE END OF AN
    ILLUSION.”

    View Slide

  18. “SYSTEMS TEND
    TO OPPOSE THEIR
    OWN PROPER
    FUNCTION.”

    View Slide

  19. “SYSTEMS
    INHERENTLY
    RESIST
    CHANGE.”

    View Slide

  20. “THE MORE ADAPTED AN
    ORGANISM IS TO
    PRESENT CONDITIONS,
    THE LESS ADAPTABLE IT
    TENDS TO BE TO
    UNKNOWN FUTURE
    CONDITIONS.”

    View Slide

  21. “IT'S CALLED
    ‘SOFTWARE’ FOR A
    REASON. IT'S
    SUPPOSED TO BE
    EASY TO CHANGE.”

    View Slide

  22. DESIGN
    SOFTWARE
    HAS A SLOW

    View Slide

  23. FAST ITERATION
    LEAN STARTUP
    AGILE
    TDD
    BDD
    KANBAN

    View Slide

  24. FAST ITERATION
    LEAN STARTUP
    VALIDATED LEARNING

    View Slide

  25. FAST ITERATION
    AGILE
    COLLABORATE

    View Slide

  26. FAST ITERATION
    TDD
    DESIGN SMALL

    View Slide

  27. FAST ITERATION
    BDD
    COMMUNICATE

    View Slide

  28. FAST ITERATION
    KANBAN
    IMPROVE CONTINUOUSLY

    View Slide

  29. (broad generalisations)

    View Slide

  30. DESIGN
    GOES DEEPER
    DOMAIN-DRIVEN

    View Slide

  31. DOMAIN
    PROBLEM SPACE
    DOMAIN MODEL
    SOLUTION SPACE

    View Slide

  32. DOMAIN
    &
    DOMAIN MODEL
    IN SYNC
    KEEP

    View Slide

  33. UBIQUITOUS
    LANGUAGE

    View Slide

  34. DESIGN
    TACKLES
    DOMAIN-DRIVEN
    COMPLEXITY

    View Slide

  35. ACCIDENTAL
    COMPLEXITY
    ESSENTIAL
    COMPLEXITY

    View Slide

  36. DESIGN PATTERNS

    View Slide

  37. “DESIGN
    PATTERNS ARE A
    GATEWAY DRUG
    TO DOMAIN-
    DRIVEN DESIGN”

    View Slide

  38. SUPPLE DESIGN

    View Slide

  39. DECLARATIVE DESIGN

    View Slide

  40. REFACTORING

    View Slide

  41. BOUNDED CONTEXTS

    View Slide

  42. DISTILLATION

    View Slide

  43. LARGE SCALE
    STRUCTURE

    View Slide

  44. MODELLING
    WHIRLPOOL

    View Slide

  45. MODEL STORMING

    View Slide

  46. DESIGN
    MATTER ?
    DOMAIN-DRIVEN
    So WHY DOES

    View Slide

  47. INFLUENCE
    FEEDBACK
    PATTERNS
    SYSTEMS
    COMPLEXITY
    ITERATIONS
    WHY CAN’T IT BE SIMPLE?

    View Slide

  48. “A LARGE SYSTEM,
    PRODUCED BY EXPANDING
    THE DIMENSIONS OF A
    SMALL SYSTEM,
    DOES NOT BEHAVE
    LIKE THE SMALLER
    SYSTEM”
    JOHN GALL

    View Slide

  49. verraes.net
    mathiasverraes

    View Slide

  50. verraes.net
    mathiasverraes

    View Slide