架构误区系列 21：生造的“合约”概念

我们日常在做架构的时候往往会有一个执念：所有的产品设计都想在产品内部形成一个完美的闭环，不是太想引入外域的概念。这种执念导致的结果往往是在域内创造了大量的内部的概念。

例如，在很多产品的设计过程中，往往会创造出“合约”这么一个概念，把所有本域无法自动产生或者确定的配置，都收口于这个合约的概念下。通过使用方签约的过程，获取产品所需要的一些配置输入，比如主体、地区、用户等级、用户业务类型（MCC）等。

这种做法，参考的是一些机构或者渠道的做法。支付机构往往将一个商户（用户）抽象为一个 MID。每个 MID 有一个支付合约，里面会规定商户的一些支付条款，包括费率、时效、可用支付渠道等等。

我们可以深入的思考一下背后的原因。其实支付机构合约背后的这些要素，都是支付机构提供的服务的抽象，都是属于支付机构自己定义的概念。将这些概念抽象为一个合约，而不需要调用方每次请求的时候都传递，还要校验，这是合理的。

但是，对于内部域和域之间的交互，硬性的要把这些固有的属性再拿一个合约去聚合起来，就有点东施效颦的味道了。这种聚合，会带来两个问题：

• 使用方使用的不方便：使用方对接多个产品，每个产品都需要有一份合约的概念。使用方就需要将自己的业务要素，映射为服务提供方的合约。

• 内部概念的混乱：像主体、合约、MCC 等概念，是一个全局通用的概念。抛开这些通用的概念，而去定义产品合约这么一个不是十分清晰的概念，反而是一个退步。

所以，对于内部的交互，需要尽量杜绝这种生造概念的情况。对于合约这种东西，我们需要辩证的看待：

• 对于产品自身提供的服务能力，对于外部使用方，可以通过合约抽象。对于内部使用方，其实也没有必要生造合约，用内部的用户/商户标识去读取和校验就可以了。

• 对于通用的概念，如主体、地区、MCC 等，需要有一个全域的架构规范，形成统一的业务领域概念。内部只需要用统一的术语进行上下游的交互就可以了。对于外部，如果同样是业内通用的概念，也可以定义为术语表，用统一的概念进行交互即可。

总之，按照奥卡姆剃刀原则：如无必要，勿增实体。我们不应该生造域内孤立的概念：对于通用的概念，上下游达成共识，直接使用即可。对于产品内部定义的能力，定义清楚，上游直接消费。