业务中台规划，先从那张总对不齐的订单表说起
去年秋天在南京软件大道一栋楼里，我参加一个业务中台规划评审。投影上八十多页架构图，服务分层、能力地图、领域边界，漂亮。轮到业务方提问，财务大姐把两张订单表摊桌上：“你告诉我，为什么A渠道的退款金额和B渠道对不上？”会议室安静了三秒。我当时差点把咖啡喷出来。不是笑，是那种熟悉的懊恼——中台规划写了半年，订单主数据还没对齐。
对不齐。真的对不齐。
所以这篇不聊大词，就聊一个切口：订单类业务中台规划到底该怎么落地。业务中台规划听着宽，落到地上往往就是一张订单、一次支付、一条履约状态。对吧，先把这口锅端稳，再谈满汉全席。
那张对不齐的订单表，比PPT诚实
很多中台规划从能力地图开始，画得很爽。可业务不认。为什么？因为能力地图是抽象的，订单表是具体的。具体的东西会打脸。
我后来复盘，问题不在架构图，在规划顺序。先画服务清单，再去找业务场景，容易变成“我有什么你用什么”。反过来，先蹲在业务线看订单从创建到关单怎么走，把异常分支抠出来，才知道哪些能力真共用。比如门店自提订单，和跨境保税订单，字段长得像，状态流转完全两码事。你硬合并，后面全是补丁。
这里有个比喻。中央厨房。切配、净菜、调味包可以共享，但川菜和粤菜的火候、摆盘、出餐节奏各管各的。业务中台规划也是，共享的是可标准化的“切配能力”，不是把每道菜都做成料理包。订单中台管交易生命周期，营销玩法别硬塞进来。商品中台管SPU、SKU，别让订单表长出一堆商品属性。嗯，边界这事儿，说多了像废话，画错一笔就是半年返工。
电商订单业务中台领域边界划分示意图
那业务中台到底是个啥？我用工程视角说：把跨业务线可复用的业务能力，沉淀成有契约的共享服务，再配套组织、流程、度量。注意，不是微服务拼盘。微服务是技术形态，中台是业务能力加组织契约。缺了契约，服务就是一堆API；缺了组织，API没人维护，三个月后长草。
业务中台不是技术积木，是一份组织契约
业务中台不是技术积木，是一份组织契约
说实话，我见过太多“中台=技术项目”的坑。技术团队吭哧吭哧搭服务，业务团队继续各建各的订单表。为什么？因为中台要动排期、动预算、动考核。你让业务线把需求排进中台团队，谁定优先级？故障了谁背锅？复用率怎么算？这些不写清楚，架构图再美也是墙纸。
规划阶段至少要落三样东西。一是业务能力清单，颗粒度别太细，细到“查询订单备注”就没意思了；二是服务契约，输入输出、错误码、SLA、版本策略，白纸黑字；三是治理机制，需求评审谁参加，变更谁拍板，中台团队和业务团队怎么结算。别嫌土。土的东西救命。
我有个小观察：中台规划评审时，如果全程只有架构师在讲，业务方低头刷手机，这事儿悬。反过来，业务方开始争“这个字段到底归谁”，说明真进入落地了。争是好事，怕的是没人争，回头各做各的。
不过话说回来，组织契约也不是签完就完。中台团队容易变成“二传手”：业务提需求，中台转给研发，研发问业务，循环。怎么破？把领域负责人摁进业务场景里，季度目标绑一部分业务指标。别只考核接口数量，那会催生一堆没人调的API。接口数量好看，复用率难看，对吧。
订单中台规划，先钉死三颗钉子
切口落到订单中台，我一般先看三颗钉子：状态机、幂等与路由、数据一致性。这三颗不钉，后面全是玄学。
状态机别用一个status打天下。订单主状态、支付状态、履约状态、售后状态要拆开。主状态管交易生命周期，支付状态管钱，履约状态管货，售后状态管退换。拆开以后，各业务线可以扩展，但主流程收敛。否则一个status字段里塞“待支付、已支付、待发货、部分发货、退款中、已关闭”，再加渠道差异，维护的人会疯。状态机还要定义非法流转和补偿动作。比如支付成功但库存扣减失败，是回滚还是挂起？规划时就得写清楚，别等线上告警再拍脑袋。
订单中台状态机与幂等键设计场景图
幂等键和路由规则要前置。订单创建幂等，别只用业务单号，渠道可能重复推送。幂等键设计要考虑业务身份、渠道、外部单号。路由规则按租户、渠道、业务线分，别在代码里写if else。路由错了，订单跑到别的仓，客服电话能打爆。坦白讲，这块没有银弹，就是提前把异常场景列全，做表格，逐条过。
数据一致性靠对账，不靠信仰。订单、支付、库存、履约跨服务，强一致不现实。本地事务加消息表、定时对账、补偿任务，都是常规操作。规划阶段要定对账口径：按笔还是按金额，T+1还是准实时，差异谁来处理。别等财务大姐拍桌子才想起来。对了，SLA也要写，订单创建响应时间、查询可用性、故障恢复目标。没有SLA的中台服务，业务方不敢接。
订单中台数据一致性对账流程场景图
这三颗钉子钉完，再谈能力开放、配置化、多租户。顺序反了，容易做成演示系统。
别把中台做成万能插座
别把中台做成万能插座
误区得说几个。中台不等于统一所有业务。创新业务早期，订单模型还没稳定，硬接中台就是互相折磨。强监管、强隔离的业务，也不适合塞进共享链路。中台规划要有“不接清单”，跟接入清单一样重要。嗯，拒绝也是规划的一部分。
还有，中台不是性能瓶颈的借口。共享服务被多条业务线调用，容量评估、隔离舱、降级策略要提前做。否则大促一来，一条业务线的流量把订单中台打挂，全员排队道歉。风险还包括边界腐烂：今天塞个营销字段，明天塞个风控标记，半年后订单表又变成大泥球。得有领域守门人，定期清理。
边界在哪？订单中台管交易生命周期和核心状态，不管具体营销玩法，不管商品主数据，不管客服工单细节。跨边界靠事件和契约，别靠数据库直连。直连爽一时，后面查问题像破案。
说到底，业务中台规划不是画一张大图，是选一个切口，把契约、状态、异常、组织责任钉进去。那张对不齐的订单表，比八十页PPT诚实。先让它对齐，再谈中台的诗和远方。行，就聊到这儿。