架构误区系列 9：强扭的「复用」

最近 Review 中发现一段逻辑：

FundOrder baseOrder = convertToFundOrder(forexBookDealDTO);//其他处理逻辑
//风控咨询securityCheckPlugin.checkRisk(baseOrder, new FundContext());

脑子一时间懵住了，为啥要做这个从远期单据到 baseOrder 的转换？如果远期单直接继承了 baseOrder，直接传过去不就得了。。。

再仔细看了一下发现，远期和即期由于一些交易特性的不同，在系统中用了两个模型来承载。但是对于风控而言，关注的就是金额、交易时间、用户等信息。所以为了“复用”，开发的同学把远期模型专成了即期单模型，然后调用风控咨询组件的时候，再统一将即期模型转换成风控需要的咨询报文。

先不论远期和即期是否可以有共同的模型，在现状两者模型完全没有共性的情况下，是否有这种都专成即期模型再调用风控的必要。

作为一个架构决策，那我们来看一下两种做法的优劣：

• 两次模型映射：

• 优势：

• 只需要实现即期模型和风控咨询报文之间的转换，代码稍微简单一点。

• 劣势：

• 代码可读性较差，为何需要从远期模型转换成即期模型需要比较大的解释成本。

• 代码的可维护性较差，后续不管改变远期模型、即期模型还是风控报文，都需要考虑远期和即期的逻辑。

• 一次模型映射：

• 优势：

• 非常直观。

• 远期和即期隔离，一个模型的变化不需要回归另一个逻辑。

• 劣势：

• 代码量稍大。

从分析可以看出来，做一次模型映射无论从代码可读性和未来的可维护性上，都具备明显的优势。这个架构决策的结果其实是比较明显的。

从这个案例中，我们可以得到什么样的启示呢？

首先，复用本质上是模型的互通所以才有逻辑的复用。像上述例子中两边模型没有任何共性的前提下，这种强扭的“复用”，实在没有任何必要。没有业务语义的复用，在代码可读性上就很差。

其次，在复用的反面，我们也要考虑到隔离的必要性。明显是两类业务，因为复用，因为要硬拉一个中台逻辑出来，很有可能反而造成了两者的不独立，导致在未来的维护上成本的急剧上升。所以，在复用上，更多的是需要有独立的业务语义，甚至有独立的组织架构，这样剥离出来的通用能力才有立足点。

最后，从美学上看，我们可以画一下两个架构的图例，也明显可以看出做一次转换在美学上会更有优势一点。