1.
Guerrilla Domain Driven Design<br />All the really important stuff you need to know about Domain Driven Design<br />Jak Charlton<br />www.thinkddd.com<br />Google+ : jakcharlton@gmail.com<br />Twitter : @jakcharlton<br />

2.
“passionate and opinionated”<br />

3.
Domain Driven Design is a methodology for evolving software that closely matches our business requirements<br />

4.
Domain Driven Design is a way of thinking, and a set of priorities<br />

5.
Domain : a sphere of Knowledge, Activity or Influence<br />

6.
For most software projects, the primary focus should be on the domain and domain knowledge<br />

7.
When we set out to write software we never know enough<br />

8.
Software is an exploration, you never know where you will end up<br />

9.
Development is iterative<br />

10.
Domain driven team<br />

11.
Get Domain Experts<br />

12.
Developers and domain experts must have a close relationship<br />

13.
Modelling<br />

14.
Model out loud<br />

15.
Brainstorm and experiment<br />

16.
The model is distilled knowledge<br />

17.
Look for the deep models<br />

18.
Don’t introduce deeper models the domain experts don’t see<br />

19.
The model is the backbone of a language used by all team members<br />

20.
The Ubiquitous Language<br />

21.
Domain experts should object to inadequate terms or structures<br />

22.
Developers should watch for ambiguity or inconsistency<br />

23.
When a term appears in multiple places, you need context<br />

24.
One team, one language<br />

25.
The term Ubiquitous Language implies there is only one model in play, but there may be many<br />

26.
Keep looking at things differently, keep questioning and challenging<br />

27.
Maintain an unbroken dialog with domain experts<br />

28.
Write it down, document continually<br />

29.
Documents should talk in terms of the ubiquitous language<br />

30.
Documents must work for their living, and stay current<br />

31.
A document should not try to do what the code already does well<br />

32.
If the code doesn’t already convey something well, perhaps it should be refactored<br />

33.
Use explanatory models , technical models aren’t always good at explaining things<br />

34.
The model and implementation are intrinsically linked<br />

35.
Expose your models, and avoid abstractions<br />

36.
Refactor when the design doesn’t express the team’s understanding of the domain<br />

37.
Refactor to deeper insight<br />

38.
Refactor when important concepts are implicit in the design and can be made explicit<br />

39.
Refactor when you can make the design more supple<br />

40.
Don’t aggressively refactor for the sake of it<br />

41.
Avoid technical virtuosity<br />

42.
Make it as simple as possible, but no simpler<br />Albert Einstein<br />

43.
Complex is easy, any idiot can do complexSimple is a lot harder<br />Jak Charlton<br />

44.
Don’t risk real business value for technical purity<br />

45.
Live in the domain<br />

46.
My objective today was to make you thinkI hope I have succeeded<br />

47.
Questions?<br />