大部分互联网公司都是业务驱动的，技术与业务的定位很简单了，技术是服务于业务的。业务在不同的发展阶段，有着不同的目标，特点和挑战。技术架构也跟随之进行演进，我们今天通过一个在线教育的交易系统平台看下平台化系统阶段的一些演进特点。

发展到平台化阶段的系统，其背后普遍的业务诉求在于，业务处于一种新的探索阶段，公司期望依托于原有某一方向已沉淀的系统能力，持续建设去探索更多类似的不同场景或者不同品类的接入。这个诉求提到研发侧来说，我们就需要在原有的一套交易链路系统上进行重构，重建，形成一个交易能力的平台，在支撑原有品类和场景之上，去接入更多的场景和品类。

比如在线教育的品类可能包含：一对一教育，小班课，大班课，互动等新的授课模式，创造不同的教学品类和授课场景。那么如何基于一套交易系统去支撑如上所说的不同品类和不同业务场景呢？

开局一张图，我们先了解下全貌：

基于上图我们可以看到一些抽象的分层，这个分层和传统的架构分层其实是不一样的。这里的分层，我们期望的是围绕于商业场景和商业能力，一步步抽象，其自上而下体现商业能力，解决方案，基础的研发能力。

我个人喜欢的分层方式一般是下面这种：

1. 支撑产品、支撑场景

2. 解决方案

3. 商业能力

4. 基础能力

5. 基础设施

这种抽象方式主要是可以很好的识别出不同能力的边界，减少强依赖，提高扩展性，为后续的业务调整和组织调整实现很好的适配。

我们回到上面的图，最上面一层是我们的解决方案层，主要目标在于解决越来越多的品类和授课场景的诉求。而在其下就开始进入我们的技术能力了，通过组件的方式实现组合和复用，提高业务支持效率。底层的领域资源，其实是和上层业务透明的，他是对于公司或是组织的一种抽象，他可以支撑所有的业务组合和场景接入。

我们从抽象到具象一步步的来看，其中经过了哪些步骤：

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

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

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

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

下面的领域资源是业务的基础能力，他不会因为上层的场景或是业务变化而巨变，所以我们可以将领域资源这一层的能力看做是业务能力的支撑点。

按照大部分系统需要衔接“需求与供给”来说，我们可以将系统分层toB和toC的两部分，比如将领域资源分为平台资源与用户资源：

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

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

在任何一套交易系统中，商品都是非常核心的一个领域，是交易链路的主要资源，是交易的起点和终点。前面我们提到了，平台化交易系统诞生的主要背景在于需要支撑更多的业务场景和品类，而这些场景和品类其实在在线教育领域来说就是商品，所以对于商品的建模就非常重要。

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

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

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

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

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

设计原则：

在设计业务模型时，应遵循 KISS 原则，避免过度设计，在贴合业务的前提下，把开发维护的成本降到最低；另外，在领域划分与演进时，一定要捍卫 SOLID 原则，否则一旦容忍坏味道，业务架构将在破窗效应下快速腐化。

在有了底层资源和模型抽象之后，我们的交易系统就需要考虑如何将这些资源编排起来以适配于不同的业务场景和品类流程之下了。这里我们一般会研发独立的一套"配置-编排"系统，他其实更多的像“网关”，起到“路由”的作用。

我们通过编排或是可视化的编排，将领域资源串联起来，形成一个个的业务能力，这里的能力不是点而是线。

通过串联这些点，构成复杂多样的业务流程，一般的是针对于一套流程，抽象、泛化形成通用流程。在流程之上增加扩展点，最终构成一套标准化的业务组件。下面以用户下单为例，抽象的流程：

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

商品本身具有原价（又称划线价）和现价，二次定价指根据学生对应的销售组织或区域进行价格调整，形成比较灵活的价格体系

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

扩展点类似 JAVA 世界里的 SPI ，体现了依赖倒置的原则，可实现接口的多态性，在开发框架中使用广泛

我们通过编排与配置，将一个个的能力体现出来，但是每个能力其实只是大的解决方案的一部分，在能力之上，就是我们的解决方案层了，也就是面的部分。

当我们积累了足够多的业务组件，业务上经历了充分的试错，我们可以精选部分组件，建立一套标准解决方案，供新的业务线重复使用，也可以进一步对外提供 SaaS 服务。一套saas服务通常包含营销推广、交易数据统计、内容运营、助学互动、合作商分销、音视频终端等。

我们上面梳理了，如果基于存量的一套研发体系或是技术体系，实现多品类多业务场景的一个接入，也就是点->线->面的演进。这是一个抽象的路径，而真实的研发重构流程是一个反向的流程，就是我们需要从点的部分开始搞起，一步步向上搭建，形成最终的解决方案，比如saas。

所以如何设计好一个个的业务组件，微服务是非常重要的，因为这些将是我们组成核心解决方案的毛细血管。

提升研发效率的很关键的设计原则是：复用。实现何种层次、程度的复用，关系到最后的交付效率。所以我们需要适用于不同生命周期阶段的、多层次的服务能力。

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

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

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

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

早期业务中台的研发重点是业务组件，复用交易中心已有统一下单、统一结算页等业务组件，未来将提供更加丰富的业务组件供接入方选用。

通过流程标准化+扩展点，业务组件能够最大化的复用业务逻辑，又能够支持个性化场景，很好的平衡了接入效率和可扩展性。

“点线面”的服务体系也更加符合“小团队作战，发现有利战机，中台炮火支援，扩大战果”的中台思想

很长一个阶段组件开发方式不是理想形态，因为扩展点的定义与实现都是由业务中台负责，这违反了康威定律。

我们需要一个组件化开发平台，分离扩展点的定义与实现，让中台负责定义，前台负责实现。这样才符合中台架构的初衷：分层解决问题。

康威定律：系统边界取决于组织架构的沟通方式

总的来说通过定义了点线面体的业务能力模型，并结合交易中心的实践，是业务能力的一般构建思路。业务中台应当提炼出更多的业务组件，与各业务线紧密合作，不断打磨优化，沉淀出行业解决方案。这是个厚积薄发的过程，并非朝夕之间可以完成，需要足够的耐心和远见。