中台和平台的说法都存在，没有必要咬文嚼字两者的区别和各自定义。本da文中统一使用中台代替（比较时髦）。
上一回讲到，美丽温柔爱思考的小美入职新公司后，发现系统存在重复性建设问题，她再和领导沟通后，接到一个任务----要建设一个全公司各产品线通用的触达中台……
本节还需要借助虚拟人物小美向大家解释 通用的触达中台如何设计、中台化方案。
小美在接到系统设计的任务后，就立马工作起来。"先抽取产品流程上的共性"，小美心中记着王哥的话。于是小美忙着调研赠课、赠券两个系统的系统交互，小美发现两者最大的共性就是选取一批用户。心急的小美打算从这里入手。
小美发现现有两个系统选取用户的方式很多，包括可以指定用户 ID 列表，手机号列表。可以选择文本框输入，也可以选择文件上传。赠课系统还支持给买过某个课程的用户赠送另一门课程。而另一个赠券系统还要求具备给 购买过某一类课程的用户发放优惠券，例如购买过2023年初一秋季英语课的用户发放优惠券。小美认真的梳理每一种选取用户方式的业务逻辑……
小美认为运营创建一个赠送活动，一定要选取一批用户，那么用户部分 就可以抽取为一个模型。比如叫做 用户群组，由赠课活动关联这个用户群组。在赠送时，查询出这个用户群组的所有用户 id，然后执行赠送课程或者优惠券。
classDiagram
class UserGroup {
+int id,
+string name,
+string userIds, 给指定userId 列表发
+string phones, 给指定手机号发
+string remoteFilePath, 按上传的文件发,
+string lessonIds, 给购买过课程的用户发
+string lessonGroupId, 给购买过课程群组的用户发
+long ctime,
+long utime,
+int status,状态字段 已就绪、未就绪
}
class UserGroupRelation 用户和群组关联关系 {
+int id,
long userId,
long userGroupId,
long ctime,
long utime
}
小美考虑到之前的赠课活动、赠券活动把用户获取方式冗余在活动表，没有对用户群组抽象出单独的模型。这样的设计导致用户群组和活动耦合太重。所以小美把各种用户获取方式单独放到了用户群组表里。并在活动中关联用户群组 id。
小美在文档中也特地备注了状态字段，因为小美阅读代码时 发现课程群组构建的速度较慢，因为用户量太大，关联关系表构建完成往往需要十几分钟。 对于立即赠送的活动，可能会因为课程群组未构建完成，导致发放时失败。通过状态字段可以在前端透出用户群组是否构建完成。也可以构建完成后系统自动触发赠送活动。
同时呢，小美考虑到用户群组也需要建立关联关系，数据量也非常大，需要针对用户群组关系表进行分表。分表键定义为 userGroupId。
小美边写文档边忍不住想要写代码，她都想好了，针对不同的用户获取方式，他要使用工厂模式。定义抽象的工厂接口UserGroupCollector，由工厂类实现具体的获取 userIds 的方式。 小美心中的接口是这样的
classDiagram
class UserGroupCollector {
List<Long> fetchUserIds(UserGroup userGroup);
}
UserGroupCollector collector = UserGroupCollecotrFactory.build(userGroup);
List<Long> userIds = collector.fetchUserIds(userGroup);
小美的leader 王哥在接水时路过小美的工位，便问了小美的进度。得知小美已经设计完用户群组的数据模型了，王哥很是好奇她的方案。
针对小美的方案，王哥给小美提出了几个问题。
如果新增一种用户获取方式，系统如何扩展？
公司现有自建的文件系统性能越来越差，公司有意向使用云厂商提供的 S3 文件上传，届时系统如何扩展支持？
如果别的产品线接入了系统，如何获取其他产品线课程的购买用户？
如果未来一个用户群组十分巨大，包括上千万甚至于上亿的数据，如何扩展
小美看着王哥滔滔不绝的问了几个问题，瞳孔逐渐放大，蒙在原地，
"王哥你慢慢说，我记不住这些问题"。小美说。
王哥耐心的解释，产品和运营基于实际运营场景可能提出各种各样的需求，研发很难拒绝。系统设计阶段要考虑到未来的扩展，这样需求来的时候才能少加班。未来可能增加其他用户获取方式，例如选取某一个时间段某个课程的购买用户。如果每增加一种方式就增加字段，这种方式成本太高了。另外用户群组关联的用户规模很大，如何降低存储量，也要重点考虑下。
王哥继续补充道 未来可能会接入多种文件系统，也要预留字段对应文件获取方式。更重要的是公司不同产品线的订单系统、商品系统并不统一，如果没有对应的产品线，我们无法确定从哪里获取对应的购买用户。
小美对于来自 leader 的信息输入很感兴趣。于是她默默的在心中开始盘算如何优化现有的系统模型，因为她明白新设计的系统要最大程度的预知未来的变化，如若不然，系统架构将在紧急的需求中迅速腐化，导致无尽的线上问题和加班。
爱思考的小美将如何优化用户群组的系统模型呢？待续……
