本文为领域驱动设计系列总结的第二篇，主要对领域驱动设计概念做个介绍，本系列领域驱动设计总结主要是在Eric Evans 所编写的《领域驱动设计》 一书的基础上进行归纳和总结。本文主要介绍在领域驱动设计中如何运用模型。
一 创建模型
1.1 首先对知识建立模型
我们可以通过头脑风暴交流沟通的方式，先画一个基本的原型图，然后再这基础上不断讨论完善，一般主要有以下各有效建模的要素：
1. 模型与实现绑定。最初的原型可以简陋但需要与实现绑定起来，后续迭代都这此基础上进行扩展完善。
2. 建立一种基于模型的语言。建立一个开发和业务专家能够理解的原型图，或其他表现形式。
3. 开发一个蕴含丰富知识的模型。模型不仅只是数据模型，还需要包含各类其他知识，比如行为和强制性规则等
4. 提炼模型。不断补充和修改模型。
5. 头脑风暴和实验。通过模型演示，头脑风暴不断讨论和完善模型。
1.2 知识消化
团队各个方向一块交流消化理解模型，并不断把各方向知识补充到模型中，模型聚焦于需求分析，它与编程和设计紧密交互。通过良性循环加深团队成员对领域的理解，使他们更透彻的理解模型，并更进一步完善模型。
1.3 持续学习
团队成员需要有意识的积累知识并持续学习，并随着学习的深入不断完善的模型。领域模型中一般会隐藏着一些深层次模型，这个需要不断对领域和程序需求的理解逐步加深，有可能就会发现一些非常巧妙的抽象，也就是一些深层次模型，可以更好的解决问题。建模不止于寻找实体和值对象，还有业务活动和规则，这些都是领域的核心。
二 以模型交流
领域模型可以成为软件项目通用语言的核心，基于模型的交流更能有效的且准确的表达各自的想法。
2.1 通用语言（UBIQUITOUS LANGUAGE）
开发人员应该使用基于模型的语言来描述系统中的工作，任务和功能，这个模型应该为开发和领域专家提供一种用于相互交流的语言，领域专家也可以通过这个语言讨论需求，开发计划和特性。
通过尝试不同的表示方法消除交流的难点，然后重构代码来与新模型保持一致，解决交谈中的术语混淆问题，保证大家的理解一致。
UBIQUITOUS LANGUAGE 更改就是对模型的修改，领域专家应该抵制不合适或无法充分表达领域理解的术语或结构，开发人员应该密切关注那些将会妨碍设计的有歧义和不一致的地方。
UBIQUITOUS LANGUAGE 的设计细节主要以代码的形式表达出来，也会以图和口头交流的形式帮助表达，也可通过书面文档进行补充。如果某些部分难以理解，也可以定制一套解释性模型。
三 绑定模型和实现
模型应该和具体代码实践相结合。
3.1 模型驱动设计 (Model_Drivern Design)
软件系统各部分的设计应忠实反映模型，体现出两者间的明确对应关系。我们可以检查并修改模型，以便软件可以更加自然地实现模型。我们需要的模型不但应该满足这两种需求，还应该能够支持健壮的UBIQUITOUS LANGUAGE。
从模型中获取用于程序设计和基本职责分配的术语。让程序代码成为模型的表达，代码的改变可能是会使模型的改变。而其影响势必要波及接下来相应的项目活动。只有用代码表达模型概念时，面向对象设计的真正突破之处才彰显出来。
3.2 建模人员参与程序开发（ Hands-On Modeler)
我们通过大量讨论提炼出了一个很好的模型，然而经常会出现模型没有起到作用的情况，一般有以下两个原因：
- 1. 模型的一些意图在其传递过程中丢失了。
- 2. 模型与程序实现及技术互相影响。
所以任何参与建模的技术人员，不管在项目的主要职责是什么，都必须花时间了解代码。任何负责修改代码的人员则必须学会用代码来表达模型。每一个开发人员都必须不同程度地参与模型讨论并且与领域专家保持联系。参与不同工作的人都必须有意识地通过UBIQUITOUS LANGUAGE与接触代码的人及时交换关于模型的想法，将建模和编程过程完全分离是行不通的。
那么怎么运用领域模型？
我们首先需要根据知识创建一个初步模型，并持续完善模型，接着团队内部需要基于模型总结出一套UBIQUITOUS LANGUAGE 进行日常交流，使沟通更有效率。最后我们需要将模型落地到代码设计中，我们应该通过 Model_Drivern Design
及 Hands-On Modeler的方式确保模型可以很好的与代码设计相结合。简单来说就是运用领域模型去更有效的交流与推动更好的代码设计。
