DDD概念复杂难懂，实际落地如何设计代码实现模型？

写在前面：

今天我接着跟大家聊一聊，DDD概念复杂难懂，实际落地如何设计代码实现模型。或许你是刚看到关于这部分的内容，想着这里我有必要多说一句，关于这个话题，框架上，分为这样两部分讲的：方法篇 + 实践篇。

前一部分，方法篇。旨在详细介绍DDD所包含的几个核心概念，以及围绕这些概念所构建的DDD代码实现模型的组成结构。至于为何有必要讲，上一篇开头我有明确告诉大家。

另外，考虑到有的朋友可能才刚点进来，还没看过上一篇，或者没来得及看，故而这里也再点明说一下 我想分享这一话题的必要性，以便于帮你快速知晓可以或多或少有哪方面的收获。

开门见山说，可惜的是，目前业界关于如何实施这些概念，并没有一套统一的标准和规范，这就导致我们在具体的开发过程中，常常感到无从下手。

为此，本文专门提炼了一整套DDD代码实现模型。

此外，关于看的方式，我多说一句。基于是分为前后两部分更新发布的，这就涉及到先后了。若上一篇你还未看，朋友，建议你可以先花上几分钟，或者结合文章中大小标题的思路引导，大致了解下行文框架。咱们可以过完上一篇，再进入这篇的分享，结合着，效果更好。

​01 如何设计DDD代码实现模型？

在分析DDD代码实现模型时，对于上一篇提到的四个组成部分，我们需要梳理它们的代码结构和依赖关系。针对代码结构，我们需要明确代码包的组成，以及内部所包含的技术组件。

在明确了包结构之后，依赖关系指的是我们需要进一步明确这些代码包和技术组件之间的交互关系。基于这两点，让我们先来讨论领域对象的代码实现模型。

▶︎  领域对象代码实现模型

针对领域对象，我们通常用“domain”这个单词，对代码包结构的顶层包进行命名，在该包结构下的所有技术组件，都属于领域对象的范畴。

具体而言，在DDD中，领域对象包括领域模型对象、领域事件、资源库以及应用服务所涉及到的命令和查询对象，其中领域模型对象可以分为聚合、实体和值对象这三大类。

因此，在DDD所有的代码实现模型中，领域对象涉及的代码结构最为复杂，可以分成两个层次，如图1所示。

图1

可以看到，这里的“domain”代表整个领域对象，而“model”则代表领域模型对象，请注意这两者在命名上的区别，以及它们之间的从属关系。领域对象是DDD代码实现模型的基础，包含核心业务逻辑的实现。

▶︎  应用服务代码实现模型

类似地，针对应用服务，我们通常使用“application”来命名顶层包结构。应用服务包含查询服务和命令服务这两大类，所以在子包的命名上，也会用“commandservice”和“queryservice”加以区分，如图2所示。

图2

显然，命令