Read Chapter 1, 2, 3, 9 and 14 to get a overview before dig deep into DDD

Chapter 1: Crunching knowledge

• Ingrediant of effective modeling
  • Model and implementation are consistance
  • Construct a language base on model
  • Model should be knowledge rich
    • Contain the behavior of enforced rules
  • Distilling model
    • May need to add or remove concepts
  • Execrise and test the model we design
• Knowledge crunching
  • Organise and abstract knowledge
• Continuous learning
  • Knowledge on a project is fragmented
  • Outsourcing deliver code but not knowledge
• Knowledge-rich design
  • Extract hidden concept (Finding nouns in conversations)
    • Need the programmers and everyone understand the nature of business rule
    • To get feedback from business experts, programmer need to show them tech artifacts

Chapter 2: Communication and the use of language

• Model base communication is not limited to UML
• People who can understand both business and technical jargon become bottleneck of information flow
  • A common language to solve this problem
• Use the model in speech
• Model is backbone of language
• Jargon contains ambiguities and contradictions.
  • Lack the more subtle and active feature the developer created in code
  • So we need to distillate jargons
• One team, one language
• Behaviour and constraints on model are not so easily illustrated
  • UML can help
    • but it is too time consuming
    • UML cannot convey two of the most important aspects of a model
      • The meaning of the concepts it represents
      • What the object are meant to do
• Code generated tool are counter productive
  • UML have their own limitation
• Comprehensive diagram fail to communicate or explain
  • There are too much details which will overwhelm readers
  • Use diagram to help communication and explain model, not describe the model
• Written design documents
  • Code as design documents will overwhelm user with detail
  • Code supply detail, document should complement the code and the talking
  • Terms explained by design docuent should be used in language
• Model should underlie implementation, design and team communication
  • Having separate models of these separate purposes poses a hazard
  • One exception is explanatory models
    • For education only, not need to nor suppose to be accurate
    • No UML, not use for software design