项目总结：复杂业务场景的设计与实现

我理解的复杂业务场景，指的是处理链路长（一个完整流程需要多个节点处理），链路中某个节点的分支情况多（同一节点下根据不同业务类型有不同的处理逻辑），数据结构繁多且复杂（数据流入时结构越复杂，则说明处理内容增加，业务场景更为复杂）

对于复杂的业务场景，建议可以从下面几个方面参看处理：

1.将处理链路分模块进行处理和管理

通过分模块，可以让各个子单元只关注与自己负责的内容，降低系统耦合程度，降低项目运维成本

2.通过外观法和模板方法结合使用，增加系统可维护的能力

举个例子，比如电脑启动，我们可以写个方法，里面只有四条逻辑，主板通电/显示器通电/鼠标键盘通电/内存数据处理，但是具体的逻辑放到单独的方法里面。在长链路的处理中，我们通过外观的方式，可以让整个业务流程清晰可见，项目结构越是清晰，代码可读性就越高，程序运维成本就越低

3.中台思想和扩展点的应用

通过中台提供通用功能和流程，通过扩展点实现特定品类业务场景的定制化逻辑，但是扩展点的实现的最优解是通过框架去支持和实现（阿里这边也是有特定框架的）。中台思想+扩展应用+logic，完成通用逻辑i和定制化逻辑的完美组合，解耦了复杂性~

4.数据结构的处理

逻辑复杂性已经得到处理，但是不同业务品类它们的数据结构是否通用？是否有定制化？如果是通用的还好处理，如果不通用，是采用关系型数据存储还是非关系型数据存储？现在先讨论关系型存储的解决方式，关系表中添加扩展字段，还是不同品类增加新表？在增加扩展字段后，因为不同品类流程入参可能不一致，中台接口需要兼容所有入参？如果流程入口只有一个，接口肯定只能有一处，最终的形式为扩展应用作为中台的一个子模块；如果不同品类之间，流程入口不一样，比如品类A有个单独的商城，品类B有个单独的商城，那么，整个流程入口就可以有多个，扩展应用分别提供入口，此时中台应用便成了扩展应用的服务提供方。扩展应用提供接口，并调用中台服务完成整个逻辑处理

数据结构明明准确