Domain Driven Design - DDDSydney 2011

9,723 views

Published on

Published in: Technology, Business
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
9,723
On SlideShare
0
From Embeds
0
Number of Embeds
6,515
Actions
Shares
0
Downloads
66
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide
  • DDD is a way of thinking, a set of priorities.DDD is a methodology for evolving software that closely matches our business domainsAlthough the book includes a fair bit of code, and a fair number of software patterns these are the least important bitIt is about thinking differentlyIt is about changing our priorities from the technical problem, to the business problemSoftware projects rarely fail due to technical constraints or decisions – they usually fail due to not understanding the problem
  • DDD is a way of thinking, a set of priorities.DDD is a methodology for evolving software that closely matches our business domainsAlthough the book includes a fair bit of code, and a fair number of software patterns these are the least important bitIt is about thinking differentlyIt is about changing our priorities from the technical problem, to the business problemSoftware projects rarely fail due to technical constraints or decisions – they usually fail due to not understanding the problem
  • DDD is a way of thinking, a set of priorities.DDD is a methodology for evolving software that closely matches our business domainsAlthough the book includes a fair bit of code, and a fair number of software patterns these are the least important bitIt is about thinking differentlyIt is about changing our priorities from the technical problem, to the business problemSoftware projects rarely fail due to technical constraints or decisions – they usually fail due to not understanding the problem
  • This term has become widely abused and bastardisedIn DDD, a Domain is a “Sphere of Knowledge, Activity or Influence”In Amazon terms, Ordering is a Domain, Fulfillment is a Domain, Shipping is a Domain, Accounts is a DomainA Domain represents a tightly related area of business activity
  • Too often we lose track of this fundamental conceptThe Domain represents an area of activity in our businessesSo that’s where our software project should be focusedWe get distracted by too many other things – we need to keep pulling back to the domain and the knowledge around the domain
  • Software is a wicked problem.Until you actually finish a piece of software it is impossible to estimate how long it will take to completeOr put another way, it takes just as long to accurately estimate as it does to complete it(which never stopped project managers wanting an estimate)But, as we progress, we learn moreEstimates get more accurateWe understand the problem betterWe get closer to a solution
  • Life is a journey, the destination sucks – but if you stop and look around once in a while, you might at least enjoy the ride.Software is an exploration into the unknown.Sure sometimes you have CRUD App 0003 to write – and you know pretty much what you’re gonna do – in that case don’t use DDDBut if you have a real business problem to solve, then it’s unlikely you know the way to get to the finished product yetAnd you probably don’t even know what the finished profuct looks likeScrum is keen on the concept of “Definition of Done” – well the bad news for scrum is, there really isn’t one – there are shades of DoneYou’ll know when you get there- till then enjoy the journey
  • Whether you follow Agile, Scrum or Waterfall – Development is an iterative craftPerformance, Feedback, RevisionDo something, validate it, revise it – repeat
  • Software is a team sportNot only a development team – but a domain driven teamA team that includes the domain experts, the users, the BAs and managers, the CTOIf you don’t play as a team, then you can certainly expect to fail as one
  • Not just users, not BAs – Domain Experts really know
  • It is essential in softwaredevelopemnt that you maintain a close relationship between the people developing the software and the expertsDomain experts have a deep understanding of the businessDevelopers have a deep understanding of computersThese are the people who must work closely together
  • Brainstorm and experimentDDD really promotes visibility – speak to people, use whiteboards, use cards, post it notes, blu tack and big marker pensDraw things out, throw ideas around. Talk about terms that don’t make sense, or you don’t understand.Explain things that others don’t understandIf you can’t explain something properly, you don’t understand it either.
  • The model is the latest version of all the knowledge the team has gathered about the problemIt is the essence of everything you know at any point in timeIt is probably never done, just like the Sistine chapel, but it should always be getting closer to the problem
  • A deep model provides a lucid expression of the primary concernsof the domain experts and their most relevant knowledge while itsloughs off the superficial aspects of the domain
  • The model is the foundation of DDDThe model is the representation of the working parts in your business processAnd the model forms the backbone of the language the team uses to communicate
  • One language to rule them all, one language to bind them
  • In DDD it is important that your code is a strong representation of your domainIf your code does not closely reflect your business domain, then you are dealing in abstractions.A primary purpose of DDD is to remove abstractions
  • Keep refining your models – refactoring can take place away from the code as well as in the codeAs you refactor you will discover new places where the model needs refinement or deeper exploration
  • A supple design is easier to change and adaptMake it flexible enough to change, but rigid enough to maintain integrityAvoid rigidityLoosely coupled, highly cohesive
  • Domain Driven Design - DDDSydney 2011

    1. 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. 2. “passionate and opinionated”<br />
    3. 3. Domain Driven Design is a methodology for evolving software that closely matches our business requirements<br />
    4. 4. Domain Driven Design is a way of thinking, and a set of priorities<br />
    5. 5. Domain : a sphere of Knowledge, Activity or Influence<br />
    6. 6. For most software projects, the primary focus should be on the domain and domain knowledge<br />
    7. 7. When we set out to write software we never know enough<br />
    8. 8. Software is an exploration, you never know where you will end up<br />
    9. 9. Development is iterative<br />
    10. 10. Domain driven team<br />
    11. 11. Get Domain Experts<br />
    12. 12. Developers and domain experts must have a close relationship<br />
    13. 13. Modelling<br />
    14. 14. Model out loud<br />
    15. 15. Brainstorm and experiment<br />
    16. 16. The model is distilled knowledge<br />
    17. 17. Look for the deep models<br />
    18. 18. Don’t introduce deeper models the domain experts don’t see<br />
    19. 19. The model is the backbone of a language used by all team members<br />
    20. 20. The Ubiquitous Language<br />
    21. 21. Domain experts should object to inadequate terms or structures<br />
    22. 22. Developers should watch for ambiguity or inconsistency<br />
    23. 23. When a term appears in multiple places, you need context<br />
    24. 24. One team, one language<br />
    25. 25. The term Ubiquitous Language implies there is only one model in play, but there may be many<br />
    26. 26. Keep looking at things differently, keep questioning and challenging<br />
    27. 27. Maintain an unbroken dialog with domain experts<br />
    28. 28. Write it down, document continually<br />
    29. 29. Documents should talk in terms of the ubiquitous language<br />
    30. 30. Documents must work for their living, and stay current<br />
    31. 31. A document should not try to do what the code already does well<br />
    32. 32. If the code doesn’t already convey something well, perhaps it should be refactored<br />
    33. 33. Use explanatory models , technical models aren’t always good at explaining things<br />
    34. 34. The model and implementation are intrinsically linked<br />
    35. 35. Expose your models, and avoid abstractions<br />
    36. 36. Refactor when the design doesn’t express the team’s understanding of the domain<br />
    37. 37. Refactor to deeper insight<br />
    38. 38. Refactor when important concepts are implicit in the design and can be made explicit<br />
    39. 39. Refactor when you can make the design more supple<br />
    40. 40. Don’t aggressively refactor for the sake of it<br />
    41. 41. Avoid technical virtuosity<br />
    42. 42. Make it as simple as possible, but no simpler<br />Albert Einstein<br />
    43. 43. Complex is easy, any idiot can do complexSimple is a lot harder<br />Jak Charlton<br />
    44. 44. Don’t risk real business value for technical purity<br />
    45. 45. Live in the domain<br />
    46. 46. My objective today was to make you thinkI hope I have succeeded<br />
    47. 47. Questions?<br />

    ×