如何 DDD？其实答案都在上面的图中，图中的设计在《实现领域驱动设计》书中，被定义为战略建模（Strategic Modeling），主要包含领域、核心域、子域、通用子域、支撑子域、限界上下文、协作上下文、上下文映射图等等概念，我之前的几篇《IDDD 实现领域驱动设计》系统文章，也有过相关的介绍，说实话，我只是当时读过写过有些记忆，现在让我再说任何一个概念，基本上我说不上来，对于我个人来说，战略建模是一种宏观的建模方式，你需要站在高处去俯瞰整个系统，并需要抽离出系统所包含的业务，并将它们一一划分，这个工作是非常难的，推荐几篇战略建模相关的文章：

除了战略建模，还有一种建模方式叫战术建模（Tactical Modeling），主要包含聚合（Aggregate）、实体（Entity）、值对象（Value Objects）、资源库（Repository）、领域服务（Domain Services）、领域事件（Domain Events）、模块（Modules）等等概念。

在《实现领域驱动设计》书中，Scrum 团队（一个实际项目的开发团队）一开始就是采用的战术建模，并且在开发的过程中，他们并不知道战略建模是什么？最后导致了很多问题，书中有个节点就专门讲了“战略设计为什么重要？”，但我个人觉得，战略建模的重要也只是相对而言，它在应对大型复杂性的业务系统设计中，可以充分发挥它的特点，但针对一些相对简单的系统，还不如直接进行战术建模，比如上面说的“提到我”系统。

所以，目前来说，进行战术建模比较现实和有意义，但在进行战术建模之前，我觉得还有一个重要的工作，就是和领域专家进行交流系统业务，这个工作并不包含具体的战术建模该如何设计，比如聚合、实体啥的，和领域专家并不需要讨论这部分内容，而是系统所包含的业务，就像“提到我”系统中，我问我自己“我做这个项目的核心业务是什么？”。

领域专家并不是一个职位，他可以是精通业务的任何人。他们可能了解更多的关于业务领域的背景知识，他们可能是软件产品的设计者，甚至有可能是销售员。

好，概念说太多没什么意义，实际应用才有价值，我现在在开发一个 JS 权限申请和审核系统，就是我们园子里的 JS 权限申请，因为现在申请 JS 权限需要发邮件进行申请，对于用户申请和我们处理来说，都比较麻烦并且费时间，所以为了解决这个问题，我们想做把 JS 权限申请做成像申请博客一样，园友填写申请内容，然后我们进行后台审核，效率可以提升很多，大概就是这样的一个系统，真实的不能再真实了，毕竟园友和我们都会实际接触并使用，这也是一个相对较小的系统，我们就拿它来开刀，看看 DDD 的这把刀锋不锋利。

对于 JS 权限申请和审核系统来说，领域专家是谁？应该是园友和管理员，毕竟他们在使用这个系统，没有人比他们更了解其中的业务了，所以他们就是这个系统的领域专家，需要强调的是，虽然有时候领域专家是开发人员，但在一开始探讨业务系统的时候，一定不能牵扯到数据库和代码的设计，我们应该忘掉数据库和代码，只是单纯的站在领域专家的角度，去探讨和思考业务系统，那领域专家该如何表述这个系统的业务呢？

下面我大致的表述下：

用户填写 JS 权限申请内容，管理员后台进行审核。

有没有搞错？就这么简单？？？好像又无言以对，因为关于 JS 权限申请和审核系统，最简单的表述就是这样，但如何提炼出所蕴含的业务呢？接下来需要我们深入的探讨下，作为领域专家身份的我，绘制了一张大致的业务流程图：

上面这张图可以进行反复的修改，每个领域专家都可以发表自己的意见和建议，经过最激烈的探讨才会让业务系统更加准确，当业务系统确定好之后，我们就可以从中抽离出核心业务了，上面这张图，哪些是核心业务？哪些又是业务流程呢？我大致圈一下：

方框圈的是核心业务，圆形圈的是实体的状态变化，核心业务一般包含在最简单的描述中，比如“提到我”系统中的表述“抽离”和“通知”，还有一种区分方式：判断其是否经常发生变化，对于业务流程来说，一般是不会发生变化的，变化的是核心业务，DDD 的设计应对的就是这个变化，再大致总结下：

那领域模型关心的是哪些业务？其实就是能影响 JS 权限申请状态变化的条件，暂时不看用户申请的部分，先看下管理员审核的部分，因为是人工审核的，所以这就有人为因素的产生，这部分我们在领域模型设计的时候，就没有办法把控，所以可以把这部分排除在领域模型之外，后面 JS 权限申请状态的改变，也是由人为进行导致的，也就是说，对于领域模型来说，我们没有办法进行控制 JS 权限申请状态的改变，所以后面的状态改变我们可以看作是业务流程或者工作流程，有人可能会问：“开通 JS 权限”和“消息通知用户”，算不算是业务？其实这部分可以算是业务，因为它是状态改变后的一种行为，我们可以使用领域事件实现它。