README.md

产品族

由用户挑选自己所需要的产品，动态装配出符合用户需要的软件功能。用户的需求表单可能是单参数的，例如通过不同按钮下的订单，orderType 就不同。 用户的需求也可能是分阶段，多参数的，例如用户可能先选了专车，然后又表达了自己需要儿童座椅。有很多种装配多个 Git 仓库成为产品族的方式，但是 Autonomy 有很大差异。

产品族问题也可以理解为“最终用户编程”问题，它本质上是用户来动态装配组件，而不是每一种组合后的订单，每一种组合后的商品，完全由程序员预编程好。

单字段：预组合

最简单的实现办法是添加一个代表类型的字段，例如 orderType。这种做法就是“预组合”，把所有的可能性都提前叉乘出来，变成单个变量。 这种做法有两个节点：

• 写入 orderType：如果和用户的按钮没有一一对应关系，在写入 orderType 的时候还需要有一个汇总多变量为单变量的逻辑
• 读取 orderType：所有需要差异性的地方，都要对 orderType 进行解读

也就是 orderType 成为把多个 Git 仓库粘合起来的一个东西，大家都认这个字段的含义。这种做法会有如下问题

• 难以支持分阶段表达的需求：比如用户下单的时候是一种类型，中途经过了机场，业务含义发生了变化怎么办？更新 orderType 吗？
• 难以添加新的 orderType：加了新的值，所有读取 orderType 的地方都要更新自己的判断逻辑
• 组合爆炸：如果变化的维度很多，叉乘出来的 orderType 可能是指数增长的

多字段：后组合

因为单字段的缺陷，所以实践中往往是一开始以单字段开局，然后很快地滑落为多字段的实现方案。然后又在两种方案之间反复横跳

• 添加新的 orderType：可以加一个值同时代表很多含义，不用修改表结构
• 添加新的字段：不关心这个字段的Git仓库可以不改。然而如果很多Git仓库都关心这个字段，不仅仅都要修改，而且要改接口定义

为了避免频繁加字段，就出现了用一个 bit 来代表某个 feature 是否激活的搞法。搞一个 64bit 的 int64 字段可以代表 64 个 feature flag。

公司内会有复杂的组织架构，他们都会对什么是他们负责的有自己的看法。类型字段怎么设置并不影响给不同部门出的报表，通过离线计算总是可以算出业务线所需要口径的数据的。 要避免按照公司的组织架构来设计字段，因为组织架构不是一成不变的，会拆分也会重组。

每个 Git 仓库定义自己的“合同”

除了多字段之外，还可以通过多表来实现组合。比如对于 Order，我们可以定义另外一个 OrderShipment 表，代表快递。定义 OrderSelfPickup 表，代表自提。 通过查找这个 order 是否在 OrderShipment 中，得知这个订单是否走快递配送，以及配送的目的地。 这种做法，相当于加 feature flag，每个新的变种，都是一个新的独立 bit。 也就是压根没有 xxxType 一说，只有一堆 isXXX 这样的 feature flag。 加字段，或者加表就是麻烦，单纯从 Autonomy 的角度来说，肯定是一堆独立的 Feature Flag 更独立自主。 实际工程实践中，占主导性的考虑往往是从IO效率和稳定性出发。或者说是为了迁就落后的基础架构。

多表可以理解为每个 Git 仓库定义了自己的“合同”，自己的业务记录在自己的合同内部，而不是都由“order”来夹带。 实践中，order经常变成 Map<string, any> 这样的玩意，就是所有新的业务，都要往 order 上夹带新私货。 我们完全可以把具体类型的订单，拆分成一个独立的合同，比如常规购买，团购，周期购。 这样新加一类需求，可以用加表来实现。订单本身只提供销售额，销售时间这样的最大公约数，用来支持 GMV 统计等需求。 要不然实现统计 GMV 需求的时候又麻烦了，得一对一做网状集成，而不是都汇总到 order 上，然后做星型集成。

面向对象编程发展多年，凝结出来的一句智慧是“用组合代替继承”。用多个表来组合，就是用多个对象来组合。 本质上可以理解为一个内存中的组合对象，持久化到多个数据库表中。

虚函数 v.s. 冗余字段

我们要让一个对象，比如说，订单有如下接口

class Order {
    get totalAmount(): number {
        // 多态实现
    }

    get merchandisedAt(): Date {
        // 多态实现
    }
}

我们也可以把订单定义两个冗余字段

class Order {
    // 销售额
    totalAmount: number;
    // 销售额计入哪天
    merchandisedAt: Date;
}

如果我们有不同的合同来代表多样化的业务流程，统计销售 GMV 的工作就会很有挑战。在离散型 UI 里，我们看到了订单列表的例子，其选择就是虚方法的搞法。 如果下游是离线统计，BI 分析，冗余字段的搞法会更方便对接一些。这样就要求每种具体的合同，如果要把自己归纳为某种订单，都需要有一个对应的Order，同时冗余两个字段。 从会计的工作方式里我们也可以看到这样的做法。无论业务的原始凭证多么多样，会计都要誊写成会计账目。 某种程度上，会计的账目不也是冗余字段吗？

依赖倒置

当我们拆分出了多个合同之后，每个合同可能分布在不同的 Git 仓库里。 从依赖关系的角度来说，要尽可能避免网状的依赖关系。 比如说分佣，需要知道订单是团购单或者周期购吗？可能是无关的，只需要是一个订单就可以了。 比如说退款，需要知道团购的订单和直接购买的订单退货流程是不同的吗？可能是相同，退货申请可能和订单关联就可以了。 这就是订单做为“业务泛型指针”的作用，把订单放在依赖的最底层，所有的上层具体合同通过订单进行彼此互相引用。 类似商品等泛化的概念也是如此。 与离散型UI的拆分不太一样的地方在于，这种倒置的依赖关系是怎么工作的。 离散型UI中，底层的集成组件是利用虚函数的方式来引用上层的具体实现。 而在产品族中，底层的订单有两个和上层具体实现的互动方式：

• 强制类型转换：订单做为一个 void* 或者 interface{} 一样的无类型指针，让具体的业务代码去 downcast（强制类型转换）成自己含义下的订单。
• 数据同步：也就是每个具体的业务把数据冗余一份给订单。

小结

如果判断变化不会很多，作用域控制在单个 Git 仓库内部，可以选择单字段的模式。如果预判将来会有各种幺蛾子，需要用来集成多个Git仓库，还是选择多字段，或者多表更不容易埋坑。