【第一部分】运用领域模型
第1章：消化知识
有效的建模要素
（1）模型和实现的绑定
（2）建立了一种基于模型的语言
（3）开发一个蕴含丰富知识的模型
（4）提炼模型
（5）头脑风暴和实验
【学习心得】：千万不要用自己有限的思维规划完整的图形，持续学习、消化、输出（讨论）、沉淀，所有道理都是一致的。
第2章：交流语言与使用
模式：UBIQUITOUS LANGUAGE（通用语言）
想要创建种灵活的、蕴含丰富知识的设计，需要一种通用的、共享的团队语言，以及对语言不断的试验——然而，软件项目上很少出现这样的试验。
如果语言支离破碎，项目必将遭遇严重问题。领域专家使用他们自己的术语，而技术团队所使用的语言则经过调整，以便从设计角度讨论领域。日常讨论所使用的术语与代码（软件项目的最重要产品）中使用的术语不一致，甚至同一个人在讲话和写东西时使用的言语也不一致，这导致的后果是，对领域的深刻表达常常稍纵即逝，根本无法记录到代码或文档中。翻译使得沟通不畅，并削弱了知识消化。然而任何一方的语言都不能成为公共语言，因为它们无法满足所有的需求。
【学习心得】：在自己有限的项目经验里，说沟通成本占据项目总成本的八成都不为过，就像本书一开始的重点，就是无处不在的语言。这语言可以是人话、可以是图形、可以是表格，重点在于可以帮助项目高质量高效率的落地。这里引用歌德的一句话：“世界上的误解和懈怠，也许比奸诈和恶意更误事”。
第3章：绑定模型和实现
模式：MODEL-DRIVEN-DESIGN
严格按照基础模型来编写代码，能够使代码更好地表达设计含义，并且使模型与实际的系统想契合。
如果整个程序设计或者其核心部分没有与领域模型相对应，那么这个模型就是没有价值的，软件的正确性也值得怀疑。同时，模型和设计功能之间过于复杂的对应关系也是难于理解的，在实际项目中，当设计改变时也无法维护这种关系。若分析与设计之间产生严重分歧，那么在分析和设计活动中所获得的知识就无法彼此共享。
软件系统各个部分的设计应该忠实地反映领域模型，以便体现出这二者之间的明确对应关系。我们应该反复检查并修改模型，以便软件可以更加自然地实现模型，即使想让模型反映出更深层次的领域概念时也应如此。我们需要的模型不但应该满足这种需求，还应该能够支持健壮的UBIQUITOUS LANGUAGE（通用语言）。
从模型中获取用于程序设计和基本职责分配的术语。让程序代码成为模型的表达，代码的改变可能会是模型的改变。而其影响势必要波及接下来相应的项目活动。
【学习心得】：模型、范式与设计的基本认知时候所有沟通的基石，无论是技术人员还是领域业务人员都有必要对这些知识有一个深入的理解，切记把自己局限在自己的细节当中，用人话讲就是钉子思维。对其他工作小组的认识是一种促进大家更好合作的责任心态度，还是那句话，用宏观的视野做微观的事情。
