1.4.6 不要为了抽象而抽象

抽象的前提是共性抽取，抽象思维之所以如此重要，因为它涉及软件设计的方方面面，小到一个方法、一个类的设计，大到系统架构。有时，不合理地抽象比没有抽象对系统的伤害更大。

假如某互联网公司同时开展了电商业务和电影票业务，每条业务线都有独立的C端系统、后台交易系统（包括商品管理、订单管理、营销管理）来支持业务。为了追逐潮流，公司决定将两条业务线的订单中心合并，实现订单中台，如图1-6所示。

图1-6 并不一定正确的订单中台架构

实际上，公司经营的B2C电商业务和电影票业务，在交易形态上有较大的区别，尤其体现在订单模块的设计上，订单的状态机、数据模型和财务账务处理模式完全不同。两者并没有太多的共性模块和功能，强行将两者合并后，最终只是表面上看起来实现了订单中台，但是其中的功能模块各自独立运转，完全没有实现抽象和复用。

现在，公司管理者以为拥有了强大的订单中台，可以为快速开展新业务提供支持。很快，公司决定开展机票售卖业务，针对机票业务，有独立的C端、商品管理、促销管理。

但是当产品经理和工程师开始期待订单中台的强大功能时，却遗憾地发现：订单中台无法给机票业务提供任何现成的功能复用能力，机票的订单模型和电商、电影票都不相同。

机票业务线的设计人员面临一个尴尬的局面。

• 要么按部就班地将机票订单中心纳入订单中台，统一建设——但实际上这会严重降低开发效率，因为中台研发团队肯定不会像机票业务研发团队那样重视新业务的开展。

• 要么抛弃订单中台，机票业务研发团队独立开发订单模块，但这样做又会显得订单中台没有产生应有的价值。

此时的系统架构如图1-7所示。

图1-7 加入机票业务后的订单中台架构

可见，在不同的业务模式下，订单中心并不一定适用于中台化建设，设计人员要有足够的思辨能力，判断产品形态上是否值得抽象下沉、是否能够提供复用能力。然而，这也是软件工程设计中非常难的部分。

任何软件系统的设计都基于归纳法，而非演绎法，即软件设计人员总是通过对现有世界和业务的总结提炼，而无法通过推测演绎完成软件设计。设计人员无法对业务的未来做出预测，只能基于有限的经验，尽量保证设计的灵活性和正确性。

理解这一点非常重要，这会让你在软件设计、产品设计时心存敬畏，不会因一味地追求短期无法论证的结论而产生严重的过度设计。在实践中，对于基于抽象复用的平台建设，有以下几条建议。

（1）对于明显具备共性的模块，尽早抽象。

在B端产品的体系化设计中，很多形态的产品是具备明显共性的，我们可以尽早地进行抽象设计，这样在系统架构建设的早期就能做出正确的设计方案，而且并不会过多地增加研发工作量，相反会让未来的系统扩展更加轻松。

例如，业务系统中的统一权限管理系统、单点登录系统、组织架构系统、公告系统、短信系统等，都应该尽早完成抽象建设。

（2）对于共性不确定的模块，事后抽象。

对于统一客户视图、订单中心、商品系统等软件模块，很难判断在多业务线场景下是否能够完全复用。如果对于是否进行抽象拿不准主意，那么完全可以先不做，等业务渐渐明确后，有足够的信息做出充分的分析和判断时，再决定是否合并抽象设计。