最近有个新的业务，命名为D业务吧。为了支持业务当下和稍微可遇见的未来，把核心的模型放在了订单的模型上，为了支持业务后面几个可能的形态，确定了订单主-子表的模式：

核心的要求：

  • 主表：不要带一些强校验的东西，以乘客主要信息为主，而不是以交易信息为主
  • 子表：更多的承载交易上下文的信息

这样，当后面新增业务场景的时候，我们可以扩展不同的子表，整体的订单模型不会大动。

不过，在经过几轮跟业务、产品的讨论之后，发现这个模型，或者不是这个模型本身，而是这个方案，不是很完美。主要原因是，如果把我们的整体的业务拿出来看一下，如下图：

D是一个新的探索业务，从常规的思路理解，整体上，业务测、产品测、技术测，都会单独一条线、快速运营、快速支持，技术上，为了考虑架构的复用和扩展，一部分复用了老的技术架构，在订单模型上，刚开始的思路也是考虑单独设计。

但这套解决方案拿出来大家讨论的时候，总觉得还是有问题，因为我们确实有可能会有E、F、G业务，跟D，以及目前的业务会有一些类似，那么，怎么去整体【业务运营、产品、技术】上去设计一套灵活可扩展的方案呢？

这里面有几个关键点：

  • 运营很难去推动思考这件事：因为运营拿的是业务指标结果，不会去想着中长期
  • 产品：产品是关键，产品需要整合目前的产品架构，一方面，反向推动业务架构的改变，另一方面，正向引导技术架构的方向
  • 技术：需要往前站一步，不能只看技术的架构，而是要跟产品一起，去影响业务。

经过几番讨论，最终决策的方案如下：

可以看出，这套架构跟第一个对比而言，单纯从技术视角看，没有多少本质差异，但从整体视角去看，就会大大增加我们方案的扩展能力，后续类型的业务，从业务、产品到技术都能够得到快速复用。

这个case不一定具备普适性，但很有典型，尤其对于整体的技术负责人，或者业务架构师而言，需要有业务架构【这个地方的业务架构，就是实际的业务架构，不是技术里面的概念】、产品架构的视角，需要可以从整个链路设计可服用、快速扩展的方案。