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.

1. Folding Together DDD and Agile Quick and Sustainable Development of Complex Software Eric Evans domainlanguage.com

2. DDD is a Set of Driving Principles Focus on the Core Domain. Explore models in a creative collaboration of domain practitioners and software practitioners. Speak a Ubiquitous Language within an explicitly Bounded Context.

3. ‘We should do a nice design, but we just don’t have time.’

4. Religion ‘We should do a nice design, but we just don’t have time.’

5. ‘Modeling and design take extra time, but they pay off in the long run.’

6. Speculation ‘Modeling and design take extra time, but they pay off in the long run.’

7. Modeling and design are often the quickest path to the actual goal.

8. What is your goal? Implement this user story? Complete a releasable set of stories with an acceptable level of bugs? Deliver a release that the team can continue to extend in the next release? Deliver a clear and cohesive user experience?

9. Defining Our Terms domain A sphere of knowledge or activity. model A system of abstractions representing selected aspects of the domain. A model is a distilled form of domain knowledge, assumptions, rules and choices.

10. Non Sequitur ‘We have to get the model right first, before we write the code.’

13. What does DDD look like?

15. DDD can be undramatic. Walking through concrete reference scenarios Creative collaboration with domain practitioner Refinement of the ubiquitous language and therefore the model

16. What is a ‘special case’?

17. Green Bar!

18. Challenge your assumptions

19. Shift from Push to Pull When communications with stakeholders deteriorates. When solutions seem more complex than the problems. When velocity slows (completed work becomes a burden).

20. Ok. Time to pull!Now what do we actually do?

22. Whitepaper First Draft domainlanguage.com/processdraft Will announce second draft soon in newsletter.

23. Where To Fit It Stand Up Meetings Spike Iteration Zero Release Planning

24. Defining Our Terms 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.

25. Bounded Context Modeling and design pay off within a clean, unified, bounded context. Shared code ownership within a context. One unified context is owned by one team.

26. Not all of a large system will be well designed.

27. Focus An area of the system is recognized as a center of frequent change. An area of development is strategically important. The user experience is losing coherence.

28. Focus Triage the Ball of Mud Accept the Tidy Transaction Scripts Leave well enough alone

29. DDD Tools for Agile Practitioners Model Exploration ‘Whirlpool’ Process (Section 3 in DDD book) Context Boundaries (see Chapter 14 in DDD) Distilling the Core (see Chapter 15 in DDD) Triggers to ‘pull’ modeling when needed