代码是为用户服务的（完成用户需要的功能），但就代码（程序）而言，它首先是为开发人员服务的。有两类人员会比较关注代码：代码开发人员、代码维护人员（可能为了进行某种维护工作而需要去理解代码，从而做出调整）---------------------【这里不考虑质量检查人员也会看代码......一个认真负责的程序员，是不太会为自己的代码质量而担忧的---------他早已习惯了见名知意名称、严谨的设计、一致的缩进风格、不重复、不拖沓、......】
领域驱动设计： 了解领域 <--------->构建领域模型<------------->驱动设计（可以是图、也可以是代码实现），领域模型处于中间过程，它既是对领域的了解抽象，也能反映出对领域到底理解了多少（通过模型来表达/阐述 领域，领域知识在模型中得到体现，而书中所翻译的统一语言，其实就是模型语言【个人感觉这种语言其实很接近领域语言】，例如：在将工厂模式时，会提到Factory，Product（具体产品），等等这些概念，而这些词汇就是领域词汇，我画出UML工厂类图结构，就是一个模型（某种程度上你也可以认为它就是一个领域-----工厂模式的领域）。
而领域模型在其中起到了一个关键基点，想想看我如果脑海没有简单工厂的UML模型（领域模型不是UML图，只是通过这个UML图我可以很快想明白模式中各个角色的关系），我又如何进一步分析和深挖呢？更容易明白的例子：我理解了某个东西，于是写了一篇博客。那么下次和别人想继续讨论我理解的东西时，就可以让他看我的博文，根据我博文的描述来继续深入下去，而不是从0开始【可以发现，领域模型有利于降低知识传播的难度】。在这里博文是通过文字来描述我的想法【但是你不能说博文就是想法--------你大脑进行了转换】。
记得刚开始学习DDD时（距离现在有1年多了，大致翻了一点，很吃力，就扔下了，而在上班半年多，最近再去看，忽然觉得放不下的感觉，很多东西讲的特别好），我曾经请教别人，领域模型是类图吗？领域模型是序列图吗？后来一段时间认为领域模型就是类图....（毕竟分析领域对象我们大多数都是在用类图做分析（分析有哪些领域对象、领域对象间关系），内行看门道，外行看热闹。于是那会我就产生了类图就是领域模型，领域模型就是类图），其实如果习惯，完全可以画个方块或者使用文字来表述（大家使用类图，只是因为它便于分析，这个“类图工具”较为方便罢了）。
知乎上有人问什么是领域模型？我也很长时间迷茫过（就像认为领域模型就是类图一样），最近忽然理解，领域模型------------，模型是对复杂事务的抽象，领域----用户的问题域。
那么领域模型，就是建立模型来理解用户所在的领域（问题）。理解了什么是领域模型，感觉太空了？如何构建呢？ 于是有了实体、仓储、工厂、服务、领域概念显式化（甚至提出了Specification模式来解决），理解了主干，接着就是去学习具体的构造块和模式了。继续学习中......
本篇更多是个人理解，因此可能存在不正确和误导的地方，请批判阅读【最好是查看DDD原本】。如果有更好的想法，欢迎留言。
