运用领域模型
- 每个软件程序是为了执行用户的某项活动，或是满足用户的某种需求。这些用户应用软件的问题区域就是软件的领域。
- 模型正是解决此类信息超载问题的工具。
- 模型这种知识形式对知识进行了选择性的简化和有意的结构化。适当的模型可以使人理解信息的意义，并专注于问题。
- 模型在领域驱动设计中的作用
- 模型和设计的核心互相影响。
- 模型是团队所有成员使用的通用语言的中枢。
- 模型是浓缩的知识。
- 软件的核心
消化知识
- 有效建模的要素
- 模型和实现的绑定。
- 建立了一种基于模型的语言。
- 开发一个蕴含丰富知识的模型。
- 提炼模型。
- 头脑风暴和实验。
- 知识消化
- 高效的领域建模人员是知识的消化者。他们在大量信息中探寻有用的部分。他们不断尝试各种信息组织方式，努力寻找对大量信息有意义的简单视图。很多模型在尝试后被放弃或改造。只有找到一组适用于所有细节的抽象概念后，工作才算成功。这一精华严谨地表示了所发现的最为相关的知识。
- 知识消化并非一项孤立的活动，它一般是在开发人员的领导下，由开发人员与领域专家组成的团队来共同协作。
- 持续学习
- 高效率的团队需要有意识地积累知识，并持续学习。对于开发人员来说，这意味着既要完善技术知识，也要培养一般的领域建模技巧。但这也包括认真学习他们正在从事的特定领域的知识。
- 那些早期工作还是非常重要的。关键的模型元素被保留下来，而更重要的是，早期工作启动了知识消化的过程，这使得所有后续工作更加高效：团队成员、开发人员和领域专家等都学到了知识，他们开始使用一种公共的语言，而且形成了贯穿整个实现过程的反馈闭环。
- 知识丰富的设计
- 业务活动和规则如同所涉及的实体一样，都是领域的核心，任何领域都有各种类别的概念。知识消化所产生的模型能够反映出对知识的深层理解。在模型发生改变的同时，开发人员对实现进行重构，以便反映出模型的变化，这样，新知识就被合并到应用程序中了。
- 当我们的建模不再局限于寻找实体和值对象时，我们才能充分吸取知识，因为业务规则之间可能会存在不一致。领域专家在反复研究所有规则、解决规则之间的矛盾以及以常识来弥补规则的不足等一系列工作中，往往不会意识到他们的思考过程有多么复杂。软件是无法完成这一工作的。正是通过与软件专家紧密协作来消化知识的过程才使得规则得以澄清和充实，并消除规则之间的矛盾以及删除一些无用规则。
- 提取一个隐藏的概念
- 深层模型
- 有用的模型很少停留在表面。随着对领域和应用程序需求的理解逐步加深，我们往往会丢弃那些最初看起来很重要的表面元素，或者切换它们的角度。这时，一些开始时不可能发现的巧妙抽象就会渐渐浮出水面，而它们恰恰切中问题的要害。
- 在一个需要团队成员持续学习的真实项目中，要想建立实用且清晰的模型则要求团队成员既精通领域知识，也要精通建模技术。
- 知识消化是一种探索，它永无止境。
交流与语言的使用
- 领域模型可成为软件项目通用语言的核心。该模型是一组得自于项目人员头脑中的概念，以及反映了领域深层含义的术语和关系。这些术语和相互关系提供了模型语言的语义，虽然语言是为领域量身定制的，但就技术开发而言，其依然足够精确。正是这条至关重要的纽带，将模型与开发活动结合在一起，并使模型与代码紧密绑定。
- 这种基于模型的交流并不局限于 UML 图。为了最有效地使用模型，需要充分利用各种交流手段。
- 模式：UBIQUITOUS LANGUAGE
- 要想创建一种灵活的、蕴含丰富知识的设计，需要一种通用的、共享的团队语言，以及对语言不断的试验
- 如果语言支离破碎，项目必将遭遇严重问题。领域专家使用他们自己的术语，而技术团队所使用的语言则经过调整，以便从设计角度讨论领域。日常讨论所使用的术语与代码中使用的术语不一致。甚至同一个人在讲话和写东西时使用的语言也不一致，这导致的后果是，对领域的深刻表述常常稍纵即逝，根本无法记录到代码或文档中。 翻译使得沟通不畅，并削弱了知识消化。 然而任何一方的语言都不能成为公共语言，因为它们无法满足所有的需求。
- 项目需要一种公共语言，这种语言要比所有语言的最小公分母健壮得多。通过团队的一致努力，领域模型可以成为这种公共语言的核心，同时将团队沟通与软件实现紧密联系到一起。该语言将存在于团队工作中的方方面面。
- UBIQUITOUS LANGUAGE（通用语言）的词汇包括类和主要操作的名称。
- 模型之间的关系成为所有语言都具有的组合规则。词和短语的意义反映了模型的语义。
- 将模型作为语言的支柱。确保团队在内部的所有交流中以及代码中坚持使用这种语言。在画图、写东西，特别是讲话时也要使用这种语言。通过尝试不同的表示方法（它们反映了备选模型）来消除难点。然后重构代码，重新命名类、方法和模块，以便与新模型保持一致。解决交谈中的术语混淆问题，就像我们对普通词汇形成一致的理解一样。要认识到，UBIQUITOUS LANGUAGE 的更改就是对模型的更改。领域专家应该抵制不合适或无法充分表达领域理解的术语或结构，开发人员应该密切关注那些将会妨碍设计的有歧义和不一致的地方。
- 讨论系统时要结合模型。使用模型元素及其交互来大声描述场景，并且按照模型允许的方式将各种概念结合到一起。找到更简单的表达方式来讲出你要讲的话，然后将这些新的想法应用到图和代码中。
- 简单、非正式的 UML 图能够维系整个讨论。绘制一幅包含当前问题最关键的 3 ～ 5 个对象的图，这样每个人都可以集中注意力。所有人就对象关系会达成一致的认识，更重要的是，他们将使用相同的对象名称。
- UML 图无法传达模型的两个最重要的方面，一个方面是模型所表示的概念的意义，另一方面是对象应该做哪些事情。
- 设计的重要细节应该在代码中体现出来。良好的实现应该是透明的，清楚地展示其背后的模型
- 互为补充的图和文档能够引导人们将注意力放在核心要点上。自然语言的讨论可以填补含义上的细微差别。
- 文档应作为代码和口头交流的补充
- 文档应当鲜活并保持最新，避免文档与项目脱节。
绑定模型和实现
- 领域驱动设计要求模型不仅能够指导早期的分析工作，还应该成为设计的基础。
- 严格按照基础模型来编写代码，能够使代码更好地表达设计含义，并且使模型与实际的系统相契合。
- 如果整个程序设计或者其核心部分没有与领域模型相对应，那么这个模型就是没有价值的，软件的正确性也值得怀疑。同时，模型和设计功能之间过于复杂的对应关系也是难于理解的，在实际项目中，当设计改变时也无法维护这种关系。若分析与和设计之间产生严重分歧，那么在分析和设计活动中所获得的知识就无法彼此共享。
- 软件系统各个部分的设计应该忠实地反映领域模型，以便体现出这二者之间的明确对应关系。我们应该反复检查并修改模型，以便软件可以更加自然地实现模型，即使想让模型反映出更深层次的领域概念时也应如此。我们需要的模型不但应该满足这两种需求，还应该能够支持健壮的 UBIQUITOUS LANGUAGE（通用语言）。从模型中获取用于程序设计和基本职责分配的术语。让程序代码成为模型的表达，代码的改变可能会是模型的改变。而其影响势必要波及接下来相应的项目活动。完全依赖模型的实现通常需要支持建模范式的软件开发工具和语言，比如面向对象的编程。
- 任何参与建模的技术人员，不管在项目中的主要职责是什么，都必须花时间了解代码。任何负责修改代码的人员则必须学会用代码来表达模型。每一个开发人员都必须不同程度地参与模型讨论并且与领域专家保持联系。参与不同工作的人都必须有意识地通过 UBIQUITOUS LANGUAGE 与接触代码的人及时交换关于模型的想法。