架构误区系列 15：生造的业务概念

最近需要对邮件发送能力进行升级，需要定义一套新的邮件模版。但是为了用户体验和 AB 测试的原因，需要新老邮件模版并存。

目前，邮件通知服务接受 userId 和通知场景两个字段，然后根据场景映射出邮件模版，根据 userId 获取用户邮箱地址，最后调用沟通平台进行邮件的发送。

同学是这样实现的：在通知场景的枚举中，将现有的场景又全部复制了一份，后面加上_v2 的后缀，形成了一套新模版的场景，然后在调用发送服务的地方，根据灰度标志，分别取出 v1 或者 v2 的场景枚举，调用邮件通知服务进行邮件发送。

这么一个简单的邮件模版升级的能力，修改了十几个类，包括：

• 通知场景枚举；

• 所有需要发送通知的地方。

这个就是典型没有回归到业务本质进行架构设计的案例。

通知场景这个枚举是有明确的业务语意的，是业务能感知的各类业务的细分。而版本这个东西，其实业务上并没有感知，只是在升级过程中 AB Test 或者灰度需要的一个概念。

所以，这两个要素是不能耦合在一起的，需要做区分。

正确的系统设计，应该是不去改变有业务语意的通知场景，而是在通知服务中根据灰度标，用不同的版本号决策出合适的邮件通知模版，再调用沟通平台。

在这个设计下，需要修改地方只有一个：

• 邮件通知服务：在其中增加灰度控制能力。

我们在做业务服务设计的时候，一定要回归的业务的本质。首先需要确定业务场景的细分，然后明确各场景下需要的业务要素及其业务语意，最后将有明确语意的业务要素映射为服务中的字段。只有这样，才能设计出和业务相贴合的服务。