供应链系统设计-中台系统设计系列（三）- 好中台的标准之稳定原则

概述

在上一篇供应链系统设计-中台系统设计系列（二）- 好中台的标准之复用原则中，我们以复用原则为主，讨论了以下3点：

前台业务效率提升：好的中台能够显著提高前台业务的效率，通过将前台业务中通用的元素能力沉淀到中台，避免重复造轮子，实现能力的复用。这种复用不仅减少了前台的工作量，也加快了业务响应速度和市场适应能力。
中台边界的合理划分：中台的边界划分应基于业务发展情况和场景需求，以复用性为原则。在业务发展的不同阶段，中台可能需要保持“小中台大前台”的架构，以便实现更多的复用。随着业务的成熟和稳定，中台可以逐渐扩展，沉淀更深层次和更广泛的业务能力，这个时候也许会慢慢形成“大中台小前台”的架构。
业务能力和原子能力的复用层级：中台的设计应当基于复用原则，将业务活动中可复用的部分抽象为业务能力，进一步细分为原子能力。这些能力的复用是中台系统设计的核心，它们可以跨越不同的前台业务场景，提供灵活、可扩展的服务。

以上就是对于好中台设计标准的复用原则的讨论。今天我们来讨论另外一个好中台的标准之一，就是中台稳定性。

同样，我们还是以上次餐厅菜品的例子，进行描述。同样的一家餐厅，提供了红烧牛肉、麻婆豆腐肉牛炖咸菜、豆腐炖咸菜四种。如下图所示：

洗摘小组将原材加工备菜：牛肉块、土豆块、豆腐块、葱花、咸菜沫。豆腐块和咸菜沫都是有的，这样四个菜品都可以复用这些备菜，所以厨师直接烹饪就可以了，大大的加快了上菜的速度。

但是有一天，厨师由于家中有事，请了一个星期的假期，从外面请了一位临时来救急的厨师。经过2天的营业，客户普遍反馈一个情况，菜品的味道之前有一点不一样了，吃起来的感觉差了一点什么。又经过3-4天的营业，反馈菜品不如之前的顾客越来越多，这可把老板给急坏了，最后由于老板的不停的催促，原来的厨师终于提前2天回来，针对菜品味道的问题。

经过厨师的确认，发现在一些菜品的制作工序上，和之前的不一样，对于麻婆豆腐的配料有3门是不一样的，对于火候和时间也存在一些差异，因此，最终导致菜品的品质存在差异。

上面提高了菜品的品质差异，我们来换一种说法就是，就是菜品品质的稳定性。因为菜品的味道会随着厨师的不同而不同，因此菜品的品质就会不稳定。

那如何来解决这个问题呢？如果不解决这个问题，如果餐厅老板要再开分店就特别难，因为对于一个餐厅来说，菜品的味道是非常重要的，决定一家餐厅是否能够留得下客户。因为一个厨师不可能同时帮2家或更多的餐厅来进行炒菜。因此，需要如何解决了菜品的拼的问题呢？

我们在讲前中后台的时候，提到了鱼你在一起的案例，因此，我们可以将备菜，加工成为预制菜，例如：红烧牛肉需要进行提前腌制，麻婆豆腐需要酱料，并且酱料还要遵循先煎后熬的烹饪工序。因此，厨师专门用来研发红烧牛肉的腌制酱料，以及烹饪工序和市场，这样可以保证红烧牛肉的品质，因为对于红烧肉来说腌制酱料是非常重要的，其实麻婆豆腐也是类似的。

因此，预制菜的本质除了客户让每个门店的能够复用，提高前台业务的执行效率外，其实来由一个非常重要能力就是，就是追求菜品品质的稳定性。

如果只能复制，不能保证菜品的品质的稳定性，那么你在鱼你在一起的餐厅中迟到菜品的味道，就是各种各样的，这样对于鱼你在一起的加盟商来说简直就是灾难。

其实，对于业务中台也是一样的，不仅仅让通过复用提高前台业务的效率，而且还需要提供中台能力的稳定性和系统的稳定性。

中台领域模型的稳定性

假设，我们中台有一个商品中心，商品中心里面会存在商品信息领域模型，商品信息分为；商品基本信息、商品扩展信息、商品销售信息和商品图片信息。

在商品基本信息中，有如图中所展示的属性，例如：商品ID、商品名称、商品昵称等等。

现在业务部门有需求，说需要在商品中根据商品的评论的数量和质量，来增加商品的热度，需要将商品在对应的品类下面，标识出来是否为热门商品。如果是热门商品，在用户搜索的时候，会把刚商品作为推荐商品展示出来。

需求非常简单，就是根据商品的评论数量和质量来确定是否为热门商品，而且评论TOP50的用户，也是热门的用户，因此，开发同学就是在商品基本信息上，加上了一个是否为热门商品的字段，以便用来标识这个商品是否热门商品。如下图所示：

写到这里，大家可以思考一下？这样合理么？

其实对于商品来说，可能被很多系统用到，例如结算系统、配送系统、库存系统等等，这些系统可能根本就不会关系，是否为热门商品，而真正关心的只有电商系统。因此，在商品基本信息模型上加上一个是否为热门商品的属性，其实只有的电商系统可以用，因此是否为热门商品，是用来做销售推荐的，类似于结算系统、配送系统、库存系统，可能从始到终都不会，而这样这做的后果是什么：

首先，增加了中台模型的复杂度。

其次，增加中台模型的不稳定性。

最后，影响到中台应用系统的稳定性。

如果有机会后面我会和大家聊聊领域模型设计，我在这边针对这个问题，最主要的原因是对于没有划定领域的边界，也就是DDD里面所说的限界上下文。是否热门商品其实不是商品的属性，热门商品主要是用来推荐，因此，我们可以看到热门商品这个概念和推荐其实是强关联。

因此，我们通过DDD的战略设计方法论中，抽象出来一个推荐的限界上下文，这样我们可以把热门用户和热门商品看成可推荐的资源，而可推荐的资源中，可以有热门用户、热门商品等，后续如果还要进行其他的资源的推荐，可以再次基础上就新型扩展了。如下图所示：

而如果我们把推荐商品的标识放到商品基本信息上，后面如果基于推荐商品衍生出来的一系列前台业务可能都会在商品领域来实现，例如：前台业务可能会按业务的不断发展，要求增加热门商品的分级，将热门分为ABC三类，分别对于ABC三门热门商品进行了定义：

A类商品：指市场需求较大、用户购买频次较高的商品，一般是大众消费品或者热门商品。例如，服装、食品、家居用品等。
B类商品：指市场需求相对较小、用户购买频次较低的商品，一般是中等消费品或者小众商品。例如，一些特色食品、文具、安防产品等。
C类商品：指市场需求较小、用户购买频次较低的商品，一般是低端的消费品或者过季商品。例如，一些廉价的小饰品、塑料餐具等。

那商品中心是不是还要承载这些相关的业务逻辑呢？答案显然不是的。因此，中台领域模型的稳定性是非常重要，对于中台的领域模型需要有严格的边界划分和明确的标准。

否则，给增加中台的复杂度，从而可能会影响的前台业务的复用。因为类似热门商品，可能在前台业务中只有一到两个销售类的前台业务系统需要，其他的大部分系统是不需要的，现在不需要，可能未来也不需要。

而如果将这些业务逻辑在商品中心实现，这样不仅仅只是复杂度的提升，最重要的是随着复杂度的提升，中台系统的模型的稳定性就是大大的下降，作为中台作为前台的基础，如果中台的模型的稳定性下降，模型中掺杂了个别前台的独有的业务逻辑，就会要求中台的变化的速度就是前台的一样的，这样的变化显然会影响到其他的前台业务使用。

而经常的性的模型变化，可能会造成系统的稳定性差，因为今天修改一下商品基本信息，明天修改一下商品扩展性，修改可能会引入大量的系统BUG，如果在某个中台重要的能力上存在BUG，对于前台的系统来说可能就是灾难，从而导致服务不可用，直接影响到业务和客户使用，从而导致重大的线上生产事故，这个是可以接受的。

以上说清楚了中台模型复杂度所带来的问题以及可能会出现的问题。接下来，我们再来看看中台能力的稳定性。

中台能力的逻辑的稳定性

之前我们在将中台复用性的时候聊过什么是中台的能力，我之前的图放在这样，方便下大家再次回顾一下：

1、从第二层和第三层来存在的前台复用的可能性，因此，我们把第二层中每个小框中的统一叫做：业务能力。

2、第二层中“商品新增”，其实可以拆分成为不同的流程节点，而商品新增流程里面也是由多个流程节点组成，所以能力与能力之间是有层级的，不能再分的能力，我们称之为“原子能力”。

业务能力和原子能力，统一成为“能力”。

既然我们清楚了什么是能力，那么说说能力的稳定性。

例如：中台商品新增的原子能力，从系统角度来看可能最底层就是由多个中台的系统的接口提供能力原子能力，例如：新增商品基础信息的接口，最初的时候，商品基本就是包括：商品名称、商品昵称、商品品牌等基本的字段，基本上没有什么复杂的逻辑。例如：淘宝、天猫和健康都是类似的，但是由于健康业务的发展，健康业务在新增商品的时候，由于是药品，国家对于精神类药品的命名是有明确要求，需要按照国家有关规定来进行命名。而且这个命名规则，对于其他的业务来说是不存在的。

因此，开发思考了一下，商品的命名规则确实是属于商品命名校验规则的一部分，所以需要放到商品商品域来进行实现。所以，这个开发的在原有接口的基础上，为健康业务新开发了一个新的新增商品基础信息接口，这个这个接口就专门给健康业务来使用，封装了国家药品的命名规范，而原有接口不变，其他的相关的前台业务系统还是调用原有接口。

这样即满足了健康业务对于前台命名规则的需求，又对原有的前台业务和新增商品基础信息接没有影响，因此，看上去非常完美。

但是，在这里大家要思考一个问题，就是在业务中台的商品域，新增商品基础信息接口，有了两个不同的实现，这个两个新增接口其实里面的逻辑是不同的，一个是适用于普通商品的新增，没有对于名称校验的定制规则，一个是接口是针对药品类商品的接口，命名规则中包含国家对于药品命名的规范，所以这个两个接口的逻辑其实不同的。

在业务中台的接口中，对于同一个接口或能力定义，默认的实现只能有一个，为什么呢？

主要是业务中台定义的能力都是通用能力，主要是能够复用的标准实现。因为每个前端的业务其实都存在自己的业务特性，如果把这些各自的业务特性全部都下沉到中台，这个对于中台来说就是灾难，如果长此以往，则中台很难做到通用，因为它充满了前台业务的各种独有的特性，从而复用性和稳定性打卡折扣，直接导致的结果是，中台腐化，对于前台的支撑速度效率会变得非常慢，从而拖累了前台的业务创新以及落地的速度，导致中台战略的彻底失败。如下图所示：

好的中台一定是开发效率成为指数级增长，而不好的中台，随着中台不断的腐化，开发效率会越来越低，并且稳定性也会下降。

写在最后的话

今天和大家主要讨论了中台系统设计中的稳定性原则，通过餐厅菜品的例子来说明中台稳定性的重要性，并进一步探讨了中台领域模型稳定性和中台能力逻辑稳定性的问题。主要总结如下：

中台稳定性的重要性：
- 类似于餐厅菜品的味道稳定性，中台系统也需要保证服务和数据的稳定性，这对于保持业务连续性和客户满意度至关重要。
中台领域模型的稳定性：
- 中台的领域模型应该具有清晰的边界和标准，避免因为不同业务需求而频繁变更，这样可以减少系统的复杂度，提高稳定性。
- 通过领域驱动设计（DDD）来定义限界上下文，可以将特定业务逻辑限制在特定的上下文中，避免污染其他领域模型。
中台能力的逻辑稳定性：
- 中台的能力应该是通用的、可复用的，并且具有一致性的实现。为特定业务定制的能力不应该影响中台的通用性。
- 例如，商品新增的原子能力应该只有一个标准实现，即使需要为特定业务（如健康业务）定制，也应该保持原有接口的稳定性，通过新增专门的接口来满足特定需求。
中台稳定性的影响：
- 中台的稳定性直接影响到前台业务的复用性和系统的稳定性。如果中台模型和能力频繁变更，会导致前台业务系统也必须频繁变更，从而影响整个系统的稳定性。
- 中台的腐化会降低开发效率，拖慢业务创新和落地速度，最终可能导致中台战略的失败。