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

领域驱动和微服务的关系

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

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

领域驱动和以往的需求分析方法的不同

以往的需求分析:

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

领域驱动的需求分析:

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

领域驱动中的主要概念:

用以分析的案例:

小程序:凑心, 匿名问答, bring heart togather!

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

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

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

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

四色建模法

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

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

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

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

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

领域划分

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