DDD领域驱动设计

几年前，我刚接触到DDD领域驱动，从网络上看了好多DDD相关的书籍、博客，也学习了很多DDD相关的开源代码。然而，不管我看多少DDD的书籍、博客、源码，DDD仍然是如迷雾笼罩，看不见虚实。

看到很多技术博客都发表了关于六边形架构的文章，也有一些关于洋葱架构的文章，然而，这些文章洋洋洒洒几千上万文字，都讲不明白什么才是六边形架构。 新事物的产生，不会是凭空而来的，往往都会有它的历史原因。

领域中的服务（service）表示一个无状态的操作，它用于实现特定于某个领域的任务。当某个操作不适合放在实体和值对象上时，最好的方式便是使用领域服务了。

不要去定义资源库是什么，而是要去明白资源库能干什么。 资源库是一个抽象，抽象适合放在领域层之中，可以被实体、值对象、领域事件、领域服务等领域层组件强耦合。

聚合是一个过程 聚合是一个过程，把紧密相连的实体、值对象，组合成一个更大的的实体、值对象，这个过程，就叫聚合（aggregation）。

DDD从来就不是什么新鲜的事物，而是由始以来就存在，只是，人们给它起了个叫“DDD”的名字而已！ DDD是一套方法论，用于指导软件工程的实施，如同CMMI一样。

值对象（value objectobject）是快照，固定不变，对象创建完成之后，就不能修改里面的所有属性。

很书籍、博客上说，实体一定是具有唯一标识（ID），于是很多人便认为，有唯一标识的就是实体。然而，值对象，也可以有唯一标识。

模块也是一个显式边界，领域模型便存在于边界之内。模块比限界上下文要小，可以做作是限界上下文的子集。 在Java语言中，package是模块的具体实现，package同等于模块，如com.compony

限界上下文是一个显式边界，领域模型便存在于边界之内。在边界内，通用语言中的所有术语和词组都有特定的含义，而模型需要准确地反映通用语言。 其实，从本质上来看，限界上下文是一个领域。

在一个团队中，构建出属于自己的通用语言是非常有必要的，好的通用语言，能让团队具备极高的沟通效率！ 通用语言，不是天然就存在的，而是在发展的过程中，不断地完善。

领域是充满着业务知识在里面，因此，首先需要把熟悉业务的人员（领域专家）融入到团队中，让领域专家充分参与到解软件开发，在领域专家的带领下，才能把领域模型构建起来。

DDD是一种方法论，是一种指导思想，从不同的视角去看DDD结果是不一样的，因此，不适合对DDD做标准化定义，也无法对DDD做标准化定义。 DDD是站在高维视角上，总览全局。

古人说，一叶而天下知秋，透过DDD的术语，我们可以初步明白，DDD到底是什么。 DDD，分为战略模式、战术模式。 战略是指导思想，是总体纲领，战术是具体的做法，是实现战略的行动方针。