什么是业务中台

一个公司往往有多个前台，多条并行业务线，都需要具有快速迭代和应对新需求的能力，而且都面临着高并发和海量数据。而且往往会出现业务之间的需求相互影响，修改和测试回归成功非常高，多个需求并行开发等问题。 所以，我们要把多个前台中共通的基础能力沉淀下来，规划成一个个完整的体系，实现服务在不同前天场景中的业务能力重用，为前台提供完整的业务解决方案。所以中台不同于独立的定制开发系统，而是一个整体解决方案，所以我们在code时要实现业务逻辑和平台逻辑分离，不同业务之间的逻辑隔离，实现一套系统支持不同玩法的业务类型，也便于定制化扩展（通过扩展点方式流程编排）。 即，中台将前台的核心能力和服务，通过梳理抽象沉淀为稳定的外化服务，通过预留的扩展点，来支持个性化扩展。中台通过业务的持续沉淀，以应对不同业务方对于(交易)流程上的差异，为业务方提供更合理的接入流程。

有些业务需要快速响应，需要随着市场和用户的需求快速进行调整和应变。而且企业的核心业务能力经常面临高并发访问和海量数据读写，所以需要中台，实现业务快速沉淀、快速支撑业务创新的价值。

交易中台

交易实际上就是买卖双方（商品/服务细节）签订契约，然后履约的全过程，其中订单表示双方履约的过程和凭证。 （商品、类目--基础服务）

订单 支付、结算 营销：拼图秒杀、优惠券/红包、满减、拍卖等

（供应链：仓储、质检、物流、采购）

订单

复杂的订单状态流转使用FSM有限状态机，解耦状态转移与业务行为，将状态从业务Service的if-else中抽离出来 指令编排架构：将业务诉求拆成不同的指令集，选取指令集中的不同指令，通过模板方法模式将指令叠加组合形成规则，组合这些规则抽象成接入模板，不同的模板支持不同的业务场景。通过职责链+process进行组件化，可插拔地进行中台建设，灵活对应不同的前台业务。

SKU面向交易单，交易单与订单同ID;写这些流程是，都是通过预留扩展点 + 编排来实现 订单号：版本号+条带编号+时间信息+订单编号+用户ID 版本号：控制订单号的版本升级 时间信息：根据时间和访问频率决定冷热数据 用户ID：分库分表时，跳过用户-订单的映射，直接锁定库表。 扣减库存：正常售卖支付减库存，促销下单减库存 拆单 前台拆单：平台店铺提交订单时的拆单，一般是按照店铺拆单 后台拆单：实际上是生成多个发货单的过程，并不是真的拆单。

应用层   2.B2C 逆向单：策略模式+抽象类，工厂模式代替new子类 3.C2B三种回收方式，通过策略模式 + 抽象类子类完成事件发送：包括下单、取消订单、验机通过、验机拒绝，工厂模式代替new子类    流程编排作用，中台仅体现在domain  

Domain核心逻辑服务   1.ID生成策略+   2.扣减库存   3.拆合单 5.中台化：对于其他模块的订单，通过扩展入参出参，实现指令化（扩展入参出参，尽量不变动核心业务代码，面向扩展开发）

入参：查询需要的信息（ID等），若是直接调用domain方法则与domain的入参一致，若是创建则含带Rich。 出参：需要返回所得值的含带VO / Id，或者强相关，或者直接Result布尔。