DDD四色建模实战之社交关系建模

一、说明

    前面介绍了DDD的建模方法和DDD中的一些通用语言等主题，这里我们通过四色建模方法来具体看几个不同行业不同领域下如何获取对象模型，进而模拟业务。

二、建模案例1–社交网站类

2.1 背景

    社交类app在互联网中一直是比重比较大的一块，可以说是得社交者得天下。通过互联网工具我们可以将这些社交信息数据化来进行传递和交换。但是不同的社交产品有着不同的社交属性，这里通过领域分析我将其分为两类，一类是基于文本信息的社交，如门户网站，微博，论坛等，另一类就是IM类，即消息通信类。这两类算是社交领域的两大特色了，因此我们重点分析一下这两类中的明星产品的基本业务模型。另一方面本文也尝试着验证如果我没做过这个领域的人通过DDD四色建模的方式如何得到一个大概的领域模型。

2.2 通用业务时序

2.3 用户关系模型

    在进行社交关系建模之前多我们先了解一下用户关系模型。在社交场景中可以说玩社交就是玩用户数据，玩用户关系，最核心的东西抓住了之后其他的都是扩张出来的。基于用户才有流量，有流量才有玩法。因此在社交领域中摸透用户关系模型是很重要的，从用户出发可以做很多事情，搞电商，搞直播，搞外卖，搞营销，搞支付交易等等。

2.4 新浪微博/博客/论坛型社交方式

2.4.1 建模步骤

1.以满足运营和管理的需要为前提，寻找需要追溯的事件或者称为关键业务时刻； 这里我们先从业务开始的第一步梳理，将这些业务事件通过时间线或者表格的形式呈现出来，2.2已经说明了在社交领域大概会有哪些业务活动发生，那么这里通过UML时序图展示一下：

    这里我们总结一下：注册账号信息;注册个人基本信息;发布信息;评论;点赞;收藏;转发；创建群组,圈子;禁言;注销账号;2.根据这些需要追溯，寻找足迹以及对应的关键业务时刻对象；

    通过上面的总结这里我们通过一张表格先大概梳理一下，同时产出四色原型图的关键业务时刻

通过上面的表格我们大概知道用户在社交平台的关键业务时刻和对象，如下图：

1.寻找关键业务时刻对象周围的人,事,物对象；    这里我们对关键业务时刻进行丰富一下，增加一些基本对象作为人,事情,物的对象,如下图：

2.从人,事,物中抽象出角色；

    这里实际上如果人,事,物中不承载信息的发起,传播,结束则很难抽象出角色，在这里的社交模型中我们很容易看出能抽象出角色的地方肯定是用户和社交平台，因此我们重新调整一下，如下图：

    用户发布信息之后肯定需要审核看有没有非法信息，这里一般有两种形式一种是机器程序自动智能审核，一种是人工审核，但是都需要有个角色去承担审核工作，这里我们抽象一个管理员的角色承担这个指责，实际上可能是运营，客服等做这些事情，更细化的话管理员这个角色需要再进行放大识别。

1.把一些描述信息用对象补足；

    这里有些文章是把描述信息当作对象的一些属性信息了，比如帖子这个对象包括哪些属性，但是还有一种功能就是我对这些对象之间互操作的关系等描述出来，因此描述这个看上去不是核心，但是会起到画龙点睛的作用。这里我们通过两种方式来完善一下基于微博/博客/论坛的四色建模图：

2.4.2 领域建设模型

    通过上面的分析和建模过程，我们得到了如下的社交领域模型，也就是说我们通过四色建模一点点分析出微博/帖子/博客这种的社交型网站的核心领域模型。

2.4.3 领域上下文分析

    从2.4.2的领域建设模型UML图中就可以看出有两个核心上下文，一个是帖子/微博/博客，另外一个就是用户上下文。我们分别在进行分析一下，在用户上下文中肯定有登陆认证，授权，用户社交关系这些子上下文或者通用上下文支持。另外一方面在微博/帖子/博客中有评论上下文，审批上下文，事件总线等支持。

2.5 扩展上下文

    当我们真正选择了一个社交方向的时候，就会去深度定制一些东西。拿微博来说，微博中会有一些数据统计，这些数据统计可能不是真正的去用户中直接抓数据，毕竟这些在读写中读的比例会大很多很多。统计上下文虽然不重要，但是我们一旦识别出来之后就很容应对一些热点数据，比如XX出轨了，XX与YY结婚了等。当我我们选择了论坛或者博客类产品之后，那么对应的配置类上下文会比较多，比如论坛皮肤，博客页面定制，权限定制，积分营销，会员等这些都慢慢扩展开了。

2.6 代码

    这里我们先分析一下业务模型，代码的话如果基于DDD构建则需要花一些时间，后续的文章会发出来一些demo样例。

三、建模案例2–社交IM类

3.1 IM类业务时序扩展

    前面已经梳理了社交类的通用业务时序，但是在最后一个业务流程中留了一个尾巴，就是如何建立纯通讯类型的IM社交产品，因此这里对其业务特性进行分析扩展了一点业务时序，来说明一下社交IM类中存在的业务活动。

3.2 微信/QQ/钉钉型社交方式

3.2.1 建模步骤

这里我们还是按之前的步骤走一遍，来熟悉一下四色建模的套路。

1.以满足运营和管理的需要为前提，寻找需要追溯的事件或者称为关键业务时刻；

第一步先不着急梳理关键业务模型，借助业务时序图来梳理一下业务活动中出现的事件，如下时序图：

1.根据这些需要追溯，寻找足迹以及对应的关键业务时刻对象；

通过上面的总结这里我们通过一张表格先大概梳理一下，同时产出四色原型图的关键业务时刻

通过上面的表格我们大概知道用户在IM应用中的关键业务时刻和对象，如下图：

1.寻找关键业务时刻对象周围的人,事,物对象；

这里我们通过业务时刻继续扩展一些人,事,物对象，但是这个比前面的社交模型更为复杂一点，因为这些业务时刻表面上看像是人,事,物，因此会比较难以识别。目前我这边想到的一个区分方法就是关键业务时刻是某个动作触发而产生的结果或者描述。人,事,物这是这些结果或者描述里面的组成部分，是客观存在的，可以不依赖这个关键业务时刻。

1.从人,事,物中抽象出角色；

前面我们从关键业务时刻中区分出了一些人,事,物。这里抽象出角色的目的是为了更好的识别关键业务时刻是由谁在什么场景下触发的。

1.把一些描述信息用对象补足；

    通过前面的分析我们已经走到这一步了，因此识别出业务关键时刻，人，事情,物上的属性则会简单一些。要说明的是这些属性不一定非要从关键业务时刻上去分析，也不一定非要从人,事,物上分析。由谁承载这些属性则是动态识别的。

3.2.2 领域建设模型

    通过四色建模分析社交关系我们其实得到了三个信息，第一个是完整的四色原型图，第二个则是下面的领域建设模型，第三个就是后面要讲到的领域上下文。

    这张图依然是全局性质的，偏静态，因此没有体现出实体，聚合的概念。当我们进行后期的设计之后会通过一些局部的图融入值对象，实体，聚合，服务等。在进行UML类图设计的时候这种形式的表现力会更加丰富，就如《领域驱动设计》里的一样，将属性，行为，实体等也加入进去。

3.2.3 领域上下文分析

    从上面的图去分析上下文其实有些难度，但是从社交领域来看其本质上是消息和关系的变化交汇，因此核心的上下文其实也就两个，一个是消息，一个是用户关系。消息这里有很多种单聊，群聊，群公告，通知，会议这些，只是这里的消息就是IM类的消息，不包括会议，待办这种的。另外一个用户关系的话也分为两类，一种个人生活中的群，好友关系。另外一种就是往企业办公方向走，这个就算是企业办公类的上下文了。总结一下这里的上下文有哪些：朋友圈（动态），消息（包括视频，直播），群，好友，企业（组织，会议，待办，团队）

3.3 扩展上下文

    我们看一下社交IM类的扩展上下文有哪些，IM类APP有很多，玩法也多种多样，微信和钉钉，以及国外的FB，twitter这些都是IM类社交产品的典型。分析出核心上下文之后，我们可以基于此做一些扩展，比如微信里的小程序，钉钉里的小程序。微信步数，公众号，支付这些。钉钉更侧重于企业上下文的扩展，比如钉钉文档，钉钉与阿里云等官方产品的融合。

四、总结

    我曾经做过一点点关于社交类产品的功能，但是对于核心模型，社交产品的玩法特色，领域分析都没做过，但是通过四色建模和领域驱动设计的理论方法也一点点分析出了社交类产品大概是什么样的。如果想获取更多行业领域内的知识并应用于实践的话，这些仅仅是一小部分工作。

原文始发于微信公众号（神帅的架构实战）：DDD四色建模实战之社交关系建模