从点到面构建交易中心服务能力

一、背景

2019 年以来，在线教育行业进入高景气周期，新的业务模式不断出现；掌门教育在巩固一对一教学基本盘的同时，又陆续开辟了小班课、大班课、AI 互动课等新的教学模式及其对应业务线，打造了多场景、多层次的线上教学体系；在这个过程中，作为各业务线的支撑平台，交易中心对原有系统进行了多次迭代升级；逐渐从一对一课程售卖链路的部分环节，发展为支持多品类课程、具有多样化营销工具以及一定数据分析能力的交易平台雏形，并且在业务的滋养下持续演进着。

本文从点线面体的角度系统阐述了交易中心业务能力的构建思路，其中案例大都限于交易领域范畴，为不失一般性，尽量对业务模型和流程进行了简化，以便供读者参考到其它业务领域。

二、业务能力的点线面体模型定义

图1 点线面体模型

如图所示，点线面体模型含义如下：

• 点：领域资源，通过设计精良的 API 暴露出来，领域划分遵循高内聚、低耦合原则，相互之间不应该有调用关系

  
  

• 线：业务组件，将点串联起来，以支持业务逻辑的复杂性和多样性，业务组件包含前端组件和后端组件，本文限定在后端组件范畴

  
  

• 面：解决方案，将线编织起来，形成业务闭环，解决方案是基于实际业务沉淀的行业标准，也可以发展为 SaaS 服务

  
  

• 体：服务治理体系，保障服务的正确性、稳定性与伸缩能力；比如，通过业务审计对分布式系统下数据不一致进行兜底处理；通过分库分表实现数据库吞吐量的线性扩展；通过聚合查询满足跨领域多条件分页查询的业务场景等

接下来，本文将从点线面三个层次阐述业务能力的构建方式。

三、领域资源-业务能力的支撑点

借鉴 Linux 系统内核态与用户态的划分，我们将领域资源分为平台资源与用户资源：

• 平台资源：维持业务平台运行所需要的资源，如商品、课程、老师等；平台资源体现了公司的业务范围，数据规模不大，增长平缓，整体可控

• 用户资源：归属于用户的资源，如订单，领取的优惠券，购买的课程等，是由用户行为产生的数据；用户数据会随着平台运行而逐步增长，甚至存在阶段性的爆发式增长；通常要预先设计好分库分表策略，以资源 ID 作为 sharding-key (分片主键)进行数据分片，提高数据库集群的整体吞吐能力

以商品为例，商品作为重要的平台资源，是交易链路的起点；交易中心能力升级的主要目的，是支持多种课程的营销与售卖；因此对课程类商品的资源模型定义尤为关键，它决定了下游系统（活动、优惠券、订单等平台资源或用户资源）的交易相关要素；

图２ 课程类商品简化模型

课程类商品的简化模型如上图所示，主要有如下考虑：

1. 商品模型不可能取代课程模型，课程资源由各业务线维护，商品只是对课程的包装；商品通过课程类型、课程识别码关联到具体课程，类似快递面单之于物流，我们只专注于把包裹送到指定地点，至于包裹里具体是什么，不是我们应该关心的

   
   

2. 课程商品由交易属性和规格属性两部分构成，交易属性是指交易流程所必须的信息，是固定字段，如价格、类型、BU 等；规格属性是和交易流程无关的信息，仅用于筛选和展示，根据课程类型而不同，可以通过规格模板设定哪些课程模型的字段作为规格属性；与交易相关的营销售卖环节，都应该根据交易属性设计业务模型与流程，这样便做到了对课程类商品的泛化，使得交易能力可以下沉，支撑不同课程的营销售卖

   
   

3. 只做适度抽象，不做过分抽象；我们只是针对课程类商品进行泛化，而不是做一个电商平台；电商系统中的一些功能模块完全可以简化甚至舍弃，比如商品类目与 SPU，我们并没有繁多的品类，定义一个课程类型的枚举就够了；课程商品模型与属性越是简单明确，下游系统出错的几率就越小

   
   

4. 基于二八原则，我们应该将重心放在核心业务的设计开发上，我们的核心业务是教学服务，若需要销售课程周边的实物类商品，如教材教具等，可以使用“APP 内开店”等业界标准化的 SaaS 方案

四、组件-业务能力的生命线

领域资源化提供了业务能力支撑点，通过串联这些点可以构成复杂多样的业务流程；如果针对一类用户任务，将流程进行泛化处理，辅以扩展点，则可以构造一个标准业务组件。以用户下单为例，泛化后的交易流程如下图所示：

图３ 下单组件对应的泛化交易流程

其中二次定价、履约方式、销售绩效计算方式等，是根据课程类型和 BU 而各不相同的。

如上表所示，我们在设计下单组件的时候，需要为二次定价、履约方式、绩效计算定义扩展点，才能将业务流程成功泛化；目前交易中心支持以（ BU，课程类型）为二元身份坐标定位扩展点，通过标准流程 + 扩展点的方式，增强接口复用性，同时也支撑了业务的多样性。

五、解决方案-业务能力的外立面

当我们积累了足够多的业务组件，业务上经历了充分的试错，我们可以精选部分组件，建立一套标准解决方案，供新的业务线重复使用，也可以进一步对外提供 SaaS 服务。

目前市面上有小鹅通、短书等在线教育解决方案提供商，提供包括营销推广、交易数据统计、内容运营、助学互动、合作商分销、音视频终端等 SaaS 服务，不需要任何开发工作，在疫情期间帮助不少线下机构开启了线上教育模式。但他们无法满足大体量教育机构的业务需求，因为头部公司总是在不停的革新与试错。比如掌门优课曾在试水小班课期间将课程放到小鹅通平台，但等业务量具备一定规模后，便需将订单、积分等用户数据导出到自有系统，才能打通营销、分销、业绩、佣金等公司自有的业务规则。

我们可以沉淀自己的解决方案，对内可以降低前期开发成本，助力业务快速试错；对外可以构建行业标准，提升影响力，产生经济价值。

六、业务组件开发是当前重心

在 2020 年之前，我们一直在“点”的层面上提供服务能力，但是接入方普遍反馈投入人力多，接入周期长，跨领域协同沟通成本高等问题；我们意识到，仅仅提供领域服务 API 是不够的，接入方需要适用于不同生命周期阶段的、多层次的服务能力。

如上表所示，我们需要进一步构建业务组件和解决方案的服务能力，完善“点、线、面”三个层次，给接入方提供更好的客户体验：

• 新业务开展前期往往希望快速上线试错，可以在既有解决方案上稍作改动或者适配，快速推向市场，获取用户反馈

  
  

• 业务量达到一定规模，获取了足够的用户数据，可以进一步打磨产品并进行效果量化，基于业务组件实现更多个性化的业务逻辑

  
  

• 新的业务场景带来业务创新，需要改进或扩充领域资源，现有的业务组件无法支持业务创新，接入方需要基于领域资源自行实现业务逻辑，经充分试错，后期可以沉淀为业务组件

当前，业务中台的研发重点是业务组件，交易中心已经有统一下单、统一结算页等业务组件，未来将提供更加丰富的业务组件供接入方选用；通过流程标准化+扩展点，业务组件能够最大化的复用业务逻辑，又能够支持个性化场景，很好的平衡了接入效率和可扩展性。

但是，目前的组件开发方式还不是理想形态，因为扩展点的定义与实现都是由业务中台负责，这违反了康威定律。我们需要一个组件化开发平台，分离扩展点的定义与实现，让中台负责定义，前台负责实现。这样才符合中台架构的初衷：分层解决问题。

七、总结与展望

本文定义了点线面体的业务能力模型，并结合交易中心的实践，阐述了业务能力的一般构建思路。

接下来，业务中台应当提炼出更多的业务组件，与各业务线紧密合作，不断打磨优化，沉淀出行业解决方案。这是个厚积薄发的过程，并非朝夕之间可以完成，需要足够的耐心和远见。

我们相信，道阻且长，行则将至。

彩蛋：关于文中提到的组件化开发平台，本猿也进行过深入思考。组件化开发平台需要解决哪些问题？技术架构是怎样的？这些问题将在下篇《组件化开发平台的建设之道》进行探讨。

相关书籍

《电商产品经理宝典》刘志远　著

《企业IT架构转型之道》钟华　著

八、作者简介

李根，掌门业务系统研发架构师，专注于业务中台方法论与建设实践。

特别鸣谢：感谢以下各位领导或同事在本文创作过程中给予的指导和帮助：

叶青、裔传洲、蒋骅琦、谢恒星、陈旭、孙艺萌

----------  END  ----------

加入掌门

往期好文

掌门用户中心稳定性探索和实践

HikariCP 监控告警实战

掌门数据闭环实践与落地-第1弹