架构误区系列 14：纯代码视角的复用

风险管理项目中，风险事件需要发送邮件和短信通知。中台的沟通系统提供通用的邮件/短信发送能力，业务线内部目前在门户系统有给商户发邮件/短信通知的能力。

所以，按照“架构原则”，负责实现的同学就考虑到需要复用门户的这个通知能力。但由于门户是面向商户的应用，所以在服务的请求参数中必须传入 merchantId。但是系统发送告警通知并没有 merchantId 这个字段，而且即使交易和指标信息中有 merchantId，也不是需要接收通知的 merchantId。同学考虑是否可以用我们在系统中入驻的测试商户，写死一个 merchantId 进行发送。

这个就是纯从代码视角考虑复用：由于本域的系统提供了这个通知发送能力，所以所有发邮件/短信的场景都应该考虑复用这个服务，即使有一些绕和别扭。

但是，我们应该这样考虑架构问题么。架构是业务场景的系统化体现。所以，我们所有的架构问题，都需要回归到业务本源场景进行思考。

针对这个通知发送能力，在我们的系统中可以细分成三类场景：

1. 对于商户的触达：包括可以通过邮件、短信、站内信，以及其他的即时通讯手段。

2. 对员工的触达：给内部的员工发送业务流程相关的通知信息。

3. 内部的广播：针对一个特定的邮件组发送通知。

所以，我们做架构设计的时候，需要对这三类场景区分对待。

对于第 3 个场景，就是最普通的，通过一个 email 地址或者邮件组进行发送。

对于第 1 个和第 2 个场景，分别应该是接受一个 merchantId 或者员工号，同时接收方的合法性进行校验后，从系统中取出注册的 email 地址、手机号进行发送。这样还可以避免由于用户信息修改导致发错的情况。

所以，最终通知相关的系统架构应该是这个样子的：

总之，我们进行应用架构设计的时候，需要回归到业务场景的本质，抽象出每一类场景的关键业务要素，然后进行合理的分层和抽象。有些看似类似的场景，如果分析后在要素要有明显的区别，需要区分提供不同的服务，而不应该强扭在一起。否则极易造成服务之间的过度耦合，同时对服务的可延展性带来负面的影响。