实例实战! 领域驱动四色建模法分析需求

领域驱动和微服务的关系

自从微服务火了之后，如何去划定微服务的界限成了团队一直讨论不休的问题。界限大了，一个库里面十几张表，又变成了以前的单体应用，界限小了，一个微服务里面就一个方法，然后还要用一个 Jvm 去跑

这时候，我们就可以用领域驱动来解决微服务界限划分问题，一个微服务代码一个领域，这样是再好不过了

以往的需求分析：

前面先画用例图，数据流图，时序图等，这些确定下来之后，然后就开始建表，然后看这些数据应该怎么存，然后怎么取，然后再怎么操作，能完成这个用例功能。

领域驱动的需求分析：

一堵无限长的墙，一盒便利贴，然后大家开始集思广益，想一想我们系统中会发生事件(代表的是状态，不是动词),今天我们以现在正在开发中的小程序：凑心为例，这是一个可以匿名问答的小程序，那么它里面的事件就有，问题已创建，答案已创建等等

领域驱动中的主要概念：

用以分析的案例：

小程序：凑心，匿名问答， bring heart togather!

事件，命令，实体，补充信息

即然有了事件，那么就会有产生事件的源头：多条命令共同作用的结果。
我们还是以问题已创建为例，先刷新名字，再输入问题，点击发送。这三个命令产生了问题已创建的事件。
在第一步刷新名字时，因为我们系统会默认给一个名字，所以这里可以加一个补充信息，刷新名字(系统会随机默认一个)

事件有源头，也会有结果，如上问题已创建事件，就是产生一个问题实体

这样，我们就把下面四色建模法，对应的概念给梳理出来了

四个颜色代码，下面这个颜色分类，

用蓝色表示命令，用红色表示实体，用绿色表示领域事件，用黄色表示补充信息

于是，上面我们创建的问题，就可以做如下表述

在问题之后，我们可以对答案也做类似分析

还有我们的用户信息，因为我们是全匿名的，所以进来之后，只获取一个 openID,没有获取手机号，也没有获取微信等信息

通过上面对事件，命令，实体的整理，我们把相关的实体整理到同一个领域中，这样就完成了使用 DDD 的四色建模！