什么是限界上下文

这里要吐槽一下目前网站上的各种不说人话系列的文章，基本上全是书本上抄过来的，根本不是正常人能理解的，DDD难怪会变成玄学，读者在搜读文章的时候几乎是奔溃的状态。

为了好理解，也可能有局限性，但为了防止被喷，这里声明只是个人理解，不保证正确性。

以我们熟悉的电商领域为例：电商领域的商品概念，必须要配合一定的语境，比如商品在销售阶段，是我们理解的商品的含义；当商品进入了运输阶段，就变成了"货物"；现在流行假一赔十，当进入保险阶段，那商品又是另一个概念。可见，同样一件商品，由于业务领域边界的不同，这些通用语言的术语就有了不同的含义。

上下文=边界，这即是业务领域的边界，也是微服务边界。

假设我们面对一个庞大的系统，或者我们要从庞大的系统解放出来，我们首先想到的就是微服务，但是这里有一个难点，如何合理拆分微服务？我们就冲这个问题去解释。我们把限界上下文拆开看，限界表示划分，划分上下文，上下文表示名词。

1）我们拆分出来的一个个微服务就是一个个上下文

    a）支付微服务 = 支付上下文

    b）交易微服务 = 交易上下文

    c）风控微服务 = 风控上下文

2）上下文映射就是微服务直接调用方式，或者说调用协议

    a）假设你们部门很强势，那你的微服务永远不变，让别人适配你的协议，微信支付协议就长这样，你爱用不用

    b）假设你们部门很弱势，你要调用别人的微服务，那你加防腐层（适配器）去调用它的服务，你要去适配微信支付协议

3）关于微服务划分合理性，我们可以用事件风暴法来指导我们拆分合理性

所以当我们需要拆分一个庞大系统的时候，首先用事件风暴把微服务合理划分出来，然后确定微服务调用关系和协议。

事件风暴

事件风暴，首先得定义什么是事件，然后围绕事件进行头脑风暴。

什么是领域事件

领域事件是领域中发生的任何领域专家感兴趣的事情。这些事件我们从用户故事中就可以提取出来，比如我们用电影票务系统来举例，这里就会产生以下事件

1）当售票员标记座位后，产生一个座位已标记事件

2）当用户确认座位后，产生一个座位已确认事件

3）当售票员收到用户的确认之后，产生一个座位已预约事件

4）可能后续还有支付动作，会产生座位已支付事件

值得一提的是：领域事件不是技术概念，而是作为通用语言的一部分和领域专家，运营人员，产品团队达成一致。这一点很重要，很多技术团队内部有各种Event事件，然后这些Event事件和产品团队介绍的时候，需要加各种补充解释，其实完全没必要，领域事件在初期就需要和产品团队达成一致。

注意，领域事件的几点约束：

1）领域事件是表示已发生的动作，通常是名词+过去式动词，比如座位已标记，座位已预约

2）领域事件一定要和领域专家相关，不是一个技术概念

但是，基于用户故事的方式，可能不能完全覆盖领域事件，所以接下来介绍一种新的挖掘领域事件的方式：事件风暴

什么是事件风暴

事件风暴：一种协作式的对复杂业务领域进行探索的讨论形式，是一种灵活易调整的轻量级的适用于DDD的建模方法（暂时不能理解没关系）。可以通俗一点：用可视化的方式让架构师，产品，领域专家头脑里的东西达成一致。

谁参与

架构师，产品经理，领域专家

什么时机

新产品初始时/老系统的重构前的梳理时

解决什么问题

扫盲并发现风险点，产品经理或者架构师并没有像领域专家一样专业的专业知识。这一点生活中也很常见，在专业的离婚协议制定中，律师这个领域专家会全程参与

准备工具

便利贴（多种颜色），白板，磁力贴，笔

实施步骤

笔者用的在线白板工具：https://www.xiaohuazhuo.com/

1）列出领域事件

事件表示已经发生的事实，可能需要保存下来，或者让别人响应。

所有决定关心的领域事件都可以列出来，命令方式为名词+过去式动词，使用橙色便利贴。

2）收集关注点和问题

热点表示关注点和问题，也可一是风险，代表这件事情值得特别关注，使用紫色标签。

比如下图的30分钟超时

3）标记命令和角色

蓝色表示决策命令，黄色表示角色，角色可以是人或者系统

决策命令：产生事件的动作，和事件一一对应

角色：决策命令一定是由某个人或者系统来完成的，可以具体化：比如售票员，定时系统

比如下图的用户和定时系统

4）外部系统

领域事件不一定由角色触发决策命令产生，也可以是外部系统，外部系统使用粉红色表示。

假设这个系统不做核销功能，整个核销功能引进外部的技术，那核销对这个系统而言就是外部系统

比如下图的核销系统

5）读模型

读模型是帮助角色在做出决策命令的时候，需要提前看到的信息，支撑角色做出决策命令，使用绿色表示

比如下图的商品信息

6）聚合

某个角色在某个聚合调用某种决策命令产生了某个事件，使用浅黄色表示

时间风暴是非常大的一张图，我们刚才讨论的是局部订单的情况，现在我们把进行缩放，把聚合找出来

为了方便看清，用辅助线标记了下，这里找出了三个聚合：用户，订单，评价

7）策略

最后，还有很多策略规则自动触发的一些动作，我们用深紫色表示

比如，评价中的黄反策略

事件风暴产物

实际上的事件风暴过程远远比上面的复杂，上面只是针对订单一个模块进行的。一张真实的事件风暴图可能入下图所示

发现界限上下文

基于事件风暴的大图，我们可以识别出里面的聚合，然后根据聚合划分界限上下文，其实就把我们微服务的边界划分出来了。

这里值得一提的是，可以视内部团队情况而定，不一定每个聚合都是一个微服务，比如团队不那么壮大的情况下，用户服务就可以包含会员，收件人等。

比如下面这种图，按照微服务划分就是3个微服务：用户微服务，订单微服务，评价微服务

之所以是这三个，是因为我们讨论的还不够深入，比如商品信息从哪儿来的，库存是如何设置的，只要讨论完了，会基于一张非常大的图进行微服务划分