程序的扩展性，复用性与中台化建设

引言

在实际的项目中，如果我们想把通用功能做成一个平台，并且更友好的支持二次开发，中台化是一个思路。中台化其实是一个阿里提出的概念，并不是行业概念。本文会弱化中台化的概念，重点突出中台化背后关于复用性和扩展性思考，这些都是程序设计的基本理念。

语言本身已经提供了复用性和扩展性，中台化的复用和扩展开发和语言本身有什么不一样的思考呢？一个词来形容，就是「限制」。

编程语言的扩展性--什么都行很多时候等于什么都不行

面向对象编程语言提供了扩展性，比如 java，自身就提供了 interface 和 Override 机制。子类可以通过实现接口或继承父类，来扩展原来程序的功能。

使用 java 语言实现的开源框架，比如 spring 或 mybatis 等。我们大部分时候都是直接使用框架功能。如果我们对框架做出很多扩展，如下图，框架升级的时候很难保证所有的接口和类不发生改变。发生升级后，我们会发现原来的扩展开发都无法匹配使用了，原来的扩展开发代码资产全部要重新开发。如果是少量的二次开发，这个调整可以接受。但对于一个支持二次开发需求的平台来说是不可接受的。

限制扩展-减少承诺，遵守承诺

为了能更好的保护已经扩展开发的代码资产，我们应该减少可扩展的范围。并尽量保证这些可扩展的 SPI(接口)的不变性。减少承诺，你才能更好的实现承诺。

平台代码分离开可以扩展部分和不可扩展部分。不可扩展部分伴随框架升级可以随便修改(第三方扩展开发无感知) ；可扩展部分尽量稳定提供历史兼容(第三方扩展开发很少受到影响) 。在保护第三方扩展开发的资产和框架自身的可持续升级之间取得平衡。

框架可扩展部分的接口第三方可以扩展，官方也可以实现了这些接口作为官方组件提供。第三方可以直接使用官方组件。虽然第三方也可以继承官方组件进行子类 overwite 掉，但这样会强化官方组件的承诺。以后官方组件进行了升级，第三方会受到影响，overwite 官方组件并不推荐。

通过上面的思考，我们得到了下图：

SDK 概念定义

可扩展部门由「可扩展接口 SPI」和「接口入参出参模型」组成，为了第三方引用方便，可以放在一个单独模块，第三方开发只需要依赖这个模块，我们称为「SDK」（Software Development Kit）或「扩展开发 SDK」或「SPI 包」。

SDK 稳定性与行业标准

扩展性 SPI 的稳定性，取决于行业需求或标准是否稳定。如果项目本身就是标准制定者，只要标准稳定扩展定义 SPI 就会稳定。第三方扩展开发遵从标准 SPI-SDK，如果标准发生改变对第三方造成的改变是必然的。反之如果你不是标准制定者，标准本身还在探索。那么 SPI 自然也就不稳定，第三方扩展开发就会不断受到影响。

其他中台概念定义

扩展开发部分满足了特定场景的需求，我们称为「垂直包」或「个性包」，实现扩展开发的部门称为「前台」或「业务前台」。

官方实现可以支持多种场景，我们称为「水平包」或「公共包」，实现公共部分开发的部门称为「中台」，中台不仅可以开发「水平包」，也可以提供平台的编排能力，或配置化能力。

中台能力赋能的多个场景，每个场景我们可以称为「业务身份」，不同的业务身份就是不同的「垂直方」，不同的垂直方不仅仅可以选择使用那些水平包，或扩展出自己的「个性包」，还可以有垂直方的流程编排和垂直配置。

前台与中台的定义与常见歧义

这里的前台不是指页面前台。前台指的是不同的业务条线，中台指的是不同业务条线的公共业务。这个概念来自与阿里，目前并不是 IT 行业的通用概念，拿阿里来说，天猫和淘宝是两个前台部门，中台部门是维护天猫与淘宝公共的业务逻辑组件。

中台重沉淀积累，前台站在中台的沉淀基础上，快速响应业务。

逻辑和模型的扩展

不仅仅接口服务可以扩展，模型也可以扩展，不同的业务身份模型发生扩展，业务身份就会表现出 DDD 中「限界上下文」的概念，在后续的「用户中台」部分会举例说明。

上文我们从程序的扩展理论来论述了复用性和扩展性，实际的项目会因为场景不同，而有不同的取舍，接下来我们来观察下在互联网系统进化过程中，关于业务资产复用性思考：

烟筒式独立开发

互联网初期更重视流量和上线速度，在初期一般会使用烟筒式开发。不同业务独立开发，如下图所示：

业务条线一和业务条线二有各自独立的研发团队，分别开发自己的系统。优点是互不影响，可以快速响应需求。缺点是会出现很多形同或相似的逻辑代码（比如示例图中的逻辑 A1，以及程序骨架中的相似调度代码）。

伴随业务的逐渐发展成熟和行业沉淀，业务条线一和业务条线二的公共逻辑越来越多。随着公司不断开拓新的市场，不断出现新的业务条线（业务三，四。。。）。新的业务条线要从头做起，无法复用业务一和业务二积累的技术积累。

组件化重用

最简单的思路就是把公共逻辑做成通用的组件，用于支持不同的业务，如下：

我们把不同业务条线的公共逻辑做成公共组件（逻辑 A1）来支持不同的业务条线。新出现业务可以重用之前的组件。

中台化

如果某一个业务条线有不同的个性需求呢？我们对需要扩展的部分抽象 SPI 接口(逻辑 A 接口和逻辑 B 接口)，支持特定业务条线自定义实现实现。

如下图。中台对 SPI「逻辑 A 接口」开发多个公共组件（逻辑 A1 组件,逻辑 A2 组件）供业务前台部门使用。前台也可以自定义 SPI「逻辑 B 接口」的实现（逻辑 B1 组件，逻辑 B2 组件）。为了协作方便，可以把前台依赖的扩展开发 SPI 接口定义统一放在 SDK 中。模块关系如下：

中台思想赋能示例-服务扩展与模型扩展

用户登录在很多系统都有涉及。我们设计一个用户中台，可以赋能不同行业。比如当我们开发一个博客系统的时候，不需要重头去思考用户登录和管理的方方面面，只需要实现我们特定的扩展 SPI。

如下图：用户核心域名暴露了用户注册和用户登录两个服务。业务框架实现了主要的业务逻辑，并把可以扩展的部分放入「SDK」模块中。用户模型也放入了「SDK」中，SPI 的入参或出参会用到这些模型。官方提供了「SDK」中台 SPI 的一些官方实现。

当我们开发博客系统的时候，博客的用户模型可以在原有模型上进行扩展，放入一些博客的用户信息(此处博客系统的垂直方在模型中已经作为 DDD 中「限界上下文」存在)。并且也可以定制开发我们博客的用户持久化方式，比如使用数据库或文件系统进行持久化。这些个性扩展(垂直包)可以只服务于一个具体的博客项目，也可以考虑博客行业的用户需求通用性，做成可以使用整个博客行业的通用扩展。

中台思想赋能示例-流程编排

我们可以针对博客列表开发多个组件（数据查询，时间排序，截断分页，关键字过滤），不同的组件编排可以组装出不同的功能。比如「最近修改」功能可以通过组装(数据查询，时间排序，截断分页)等组件编排而成。比如「全文搜索」功能可以通过组装(数据查询，关键字过滤)等组件编排而成。这些不同的功能也可以认为是不同的「业务身份」，「业务身份」和具体的功能组件列表进行关联。