DDD In Agile


Published on

Following on from the success of last year, this annual event for London's architect community will have architectural innovation as a theme this year, and particularly CQRS. At the DDD eXchange we will feature leading thinkers and architects who will share their experience and Eric Evans is the programme lead.

Published in: Technology, Education
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • That is a pretty dense statement. Over the next few hours, we’ll try to define enough terms and explain enough of what we concretely do in order to unpack this statement.
  • DDD In Agile

    1. 1. Folding Together DDD and Agile<br />Quick and Sustainable Development of Complex Software<br />Eric Evans<br />domainlanguage.com<br />
    2. 2. DDD is a Set of Driving Principles<br />Focus on the Core Domain. <br />Explore models in a creative collaboration of domain practitioners and software practitioners.<br />Speak a Ubiquitous Language within an explicitly Bounded Context.<br />
    3. 3. ‘We should do a nice design, but we just don’t have time.’<br />
    4. 4. Religion<br />‘We should do a nice design, but we just don’t have time.’<br />
    5. 5. ‘Modeling and design take extra time, but they pay off in the long run.’<br />
    6. 6. Speculation<br />‘Modeling and design take extra time, but they pay off in the long run.’<br />
    7. 7. Modeling and design are often the quickest path to the actual goal.<br />
    8. 8. What is your goal?<br />Implement this user story?<br />Complete a releasable set of stories with an acceptable level of bugs?<br />Deliver a release that the team can continue to extend in the next release?<br />Deliver a clear and cohesive user experience?<br />
    9. 9. Defining Our Terms<br />domain A sphere of knowledge or activity.<br />model A system of abstractions representing selected aspects of the domain. <br /> A model is a distilled form of domain knowledge, assumptions, rules and choices.<br />
    10. 10. Non Sequitur<br />‘We have to get the model right first, before we write the code.’<br />
    11. 11. Up Front Analysis Locks in Ignorance<br /><ul><li>Models are distilled knowledge.
    12. 12. At the beginning of a project, the team is as ignorant as it will ever be.</li></li></ul><li>Why we need DDD + Agile<br />Technology can distract us.<br />Feature-orientation can fragment our model. <br />Upfront analysis locks in ignorance.<br />
    13. 13. What does DDD look like?<br />
    14. 14.
    15. 15. DDD can be undramatic.<br />Walking through concrete reference scenarios<br />Creative collaboration with domain practitioner<br />Refinement of the ubiquitous language and therefore the model<br />
    16. 16. What is a ‘special case’?<br />
    17. 17. Green Bar!<br />
    18. 18. Challenge your assumptions<br />
    19. 19. Shift from Push to Pull <br />When communications with stakeholders deteriorates.<br />When solutions seem more complex than the problems.<br />When velocity slows (completed work becomes a burden).<br />
    20. 20. Ok. Time to pull!Now what do we actually do?<br />
    21. 21.
    22. 22. Whitepaper First Draft<br />domainlanguage.com/processdraft<br />Will announce second draft soon in newsletter.<br />
    23. 23. Where To Fit It<br />Stand Up Meetings<br />Spike<br />Iteration Zero<br />Release Planning<br />
    24. 24. Defining Our Terms<br />bounded contextA description of a boundary (typically a subsystem, or the work of a particular team) within which a particular model is defined and applicable. <br />
    25. 25. Bounded Context<br />Modeling and design pay off within a clean, unified, bounded context.<br />Shared code ownership within a context.<br />One unified context is owned by one team.<br />
    26. 26. Not all of a large system will be well designed.<br />
    27. 27. Focus<br />An area of the system is recognized as a center of frequent change.<br />An area of development is strategically important.<br />The user experience is losing coherence.<br />
    28. 28. Focus<br />Triage the Ball of Mud<br />Accept the Tidy Transaction Scripts<br />Leave well enough alone<br />
    29. 29. DDD Tools for Agile Practitioners<br />Model Exploration <br />‘Whirlpool’ Process<br />(Section 3 in DDD book)<br />Context Boundaries (see Chapter 14 in DDD)<br />Distilling the Core (see Chapter 15 in DDD)<br />Triggers to ‘pull’ modeling when needed<br />