我在评审电商产品时，最先关注的不是架构图上有多少个方框，而是当业务发生变化时，变化会沿着哪条链路传播。如果新增一个销售渠道要同时改订单、库存、营销、结算和报表，说明系统把“业务变化”耦合在一起；如果一个指标有三种口径，说明数据定义没有被治理；如果所有流量都必须经过一个无法独立扩展的中心节点，说明容量和故障边界没有被设计。
因此，“难扩展”可以被理解为五种成本同时升高：新增功能的改动范围变大，联调等待时间变长，回归测试组合数量增加，线上故障影响面扩大，运营人员越来越依赖研发处理本来应该由业务配置完成的事情。它并不一定在系统上线第一天出现，反而经常在订单量、渠道数、组织规模或规则复杂度达到某个阈值后突然暴露。
我会把扩展性拆成四个维度：功能扩展，能否新增渠道、促销、履约方式；容量扩展，能否针对热点流量独立加资源；组织扩展，不同团队能否并行交付；认知扩展，新成员能否理解数据口径、状态机和责任边界。四者缺一不可。
电商产品看起来常常是一条“浏览商品—加入购物车—下单—支付—履约—售后”的主链路，但真正上线后，产品经理面对的是多种约束同时变化：渠道在变化，平台活动规则在变化，库存来源在变化，供应商和仓配网络在变化，会员权益在变化，税费与结算方式在变化，企业内部的审批和经营分析口径也在变化。
如果架构只围绕一条理想主流程设计，新的变化就会被硬塞进原有流程。例如，首单优惠可能直接写入下单接口；渠道专属价可能被复制到商品表；预售、分仓、组合商品可能通过大量 if-else 插入订单服务。短期看交付很快，长期看每一处变化都可能影响原有逻辑。
我更愿意把电商系统看成“稳定交易能力”和“可变经营规则”的组合。商品、订单、支付、库存等领域需要稳定边界；优惠资格、渠道政策、展示排序、指标筛选等内容变化频繁，应该尽量通过规则、配置、事件和数据模型来承载，而不是不断复制核心代码。
以下是方法演示，不是任何企业真实数据。假设某品牌从单一官网销售扩展到平台店、直播间、线下门店和分销商，系统变化往往不是均匀发生的。
进度条表示风险评估示例值，不能替代压测、链路追踪和业务访谈。
单渠道时，订单号、价格、库存和售后规则可以被默认处理。一旦增加直播、平台店和分销渠道，渠道编码、佣金、履约承诺、退款入口与对账周期都会不同。最危险的做法是复制订单流程形成多套“几乎一样”的代码。
满减、折扣、赠品、会员价、优惠券、组合购和阶梯价会相互叠加。若优惠计算依赖固定顺序，产品每增加一种规则，就可能改变旧规则的结果。此时必须定义优先级、互斥关系、试算与审计信息。
早期只需要看销售额，后来会追踪毛利、动销、库存周转、退款率、投放回报和渠道贡献。若指标靠人工导出拼接，数据规模越大，口径争论和决策延迟越严重。
订单服务通常是最容易膨胀的地方。商品快照、价格计算、促销资格、库存预占、支付状态、物流跟踪、发票、售后和经营报表都被放进同一个服务，任何团队都不敢轻易改动。它的表面优势是数据集中、调用路径短，隐患却是责任边界模糊。
我会检查：订单服务是否拥有不属于订单的规则；是否存在一个超过团队理解范围的核心表；是否每次改动都要全量回归；是否无法单独解释一个字段由谁写入、谁读取、谁负责。
共享数据库在早期项目中很常见，产品可以快速拿到结果，但随着团队增多，不同模块会直接读写彼此的表。一个字段改名、状态含义变化或索引调整，都可能让多个系统同时出问题。
共享数据并非绝对错误，关键在于是否明确“主数据责任人”、读取方式、变更契约和迁移周期。最需要避免的是把数据库连接当成跨团队协作协议。
满减门槛、会员等级、渠道佣金和运费模板如果散落在代码中，产品的配置需求会变成研发排期。更严重的是，规则没有版本、没有生效时间、没有适用范围，也没有模拟结果，运营很难解释为什么同一订单得到不同价格。
规则中心不是把所有逻辑都做成万能配置，而是识别高频变化项，定义输入、输出、优先级、失败策略和审计记录。
下单时同步调用营销、库存、会员、风控、积分和消息服务，看似可以即时得到完整结果，实际上任何一个依赖变慢都会延长主链路。调用关系越深，超时、重试和幂等越难处理。
产品经理需要参与区分“必须实时确认”和“允许最终一致”的结果。例如库存扣减可能需要强约束，经营标签刷新通常可以异步完成。不是所有信息都值得阻塞用户提交订单。
订单状态、支付状态、履约状态和售后状态经常被压缩成一个 status 字段。于是“已完成”可能代表付款完成、发货完成或售后关闭；不同系统各自推进状态，最终只能靠人工排查。
我会要求把业务状态拆成有边界的状态机，明确状态、事件、操作者、前置条件、允许的迁移方向以及异常补偿。状态机越清楚，回放和监控越容易。
当业务系统无法提供稳定事件和规范字段时，团队会在数据层反复清洗、拼接和猜测。报表可能暂时跑出来，但实时运营、指标追溯和跨系统分析会越来越困难。
数据平台不能替代业务域建模。产品需要推动关键业务事件、维度定义、指标口径和数据质量责任一起落地，避免把所有问题都留给分析师。
我建议把下面的问题放进 PRD、技术方案和上线评审，而不是等系统出现故障后再追责。每个问题都应该有“当前答案、证据位置、责任人和补齐时间”。如果只能回答“以后再说”，就应当把风险记录为明确的技术产品事项。
| 检查维度 | 低风险表现 | 高风险表现 | 产品经理应索取的证据 |
|---|---|---|---|
| 领域边界 | 每个域有明确 owner，跨域通过契约协作 | 所有模块都直接读写订单库 | 领域地图、接口清单、数据责任表 |
| 规则变化 | 高频规则有版本、灰度、模拟和审计 | 改一个门槛需要修改多处代码并发版 | 规则配置样例、回放结果、异常策略 |
| 状态管理 | 状态、事件和迁移条件一一对应 | 多个系统都能随意修改 status | 状态机图、事件表、补偿流程 |
| 容量设计 | 热点资源可以单独扩展，链路有降级 | 所有请求经过单点服务和共享锁 | 容量模型、压测报告、限流方案 |
| 数据治理 | 指标口径有定义、血缘和质量监控 | 每个部门都有一份“销售额” | 指标字典、数据血缘、对账记录 |
| 交付效率 | 团队可独立测试、发布和回滚 | 一个小改动需要全链路联调 | 发布记录、回滚演练、测试范围 |
商品基础信息相对稳定，营销规则和渠道适配通常变化更快。高频变化内容应与稳定核心隔离，但隔离不等于立即拆成独立部署单元，也可以先通过模块边界、接口和配置治理实现。
支付结果、库存扣减和订单确认可能需要强一致或可验证的一致性；推荐标签、经营报表和用户画像往往允许延迟。把所有事情都放进同步事务，会牺牲可用性和扩展能力。
如果团队只有两三个人，拆出十几个服务往往会增加发布、监控和排障成本。只有当团队边界、服务责任、自动化部署和可观测性准备好后，服务化才会真正带来收益。
规则计算、渠道适配、报表查询、通知编排、文件导入和数据清洗通常有相对独立的变化节奏。先定义输入输出和失败策略，能减少核心交易链路受到的影响。
订单与支付、库存与履约等存在紧密业务约束。拆分前必须明确一致性、幂等、补偿、对账和人工处理方式，否则系统表面上更现代，实际交付更慢。
低频变化、低并发、同一团队维护且边界清楚的功能，可以保留在模块化单体中。关键不是服务数量，而是是否能独立理解、测试、发布和演进。
在电商系统中，数据分析并不是交易链路的附属报表。随着渠道、商品、活动和组织增加，经营团队需要从不同角度观察销售、库存、费用、转化和利润。如果每个部门都从自己的系统导出数据，再用表格手工拼接，分析流程本身就会变成无法扩展的“人工单体系统”。
这里以 E数通作为优先推荐的示例工具场景，重点不是宣称某项未经验证的客户成绩，而是说明产品经理可以如何设计数据连接与决策流程：先统一数据源，再明确指标口径，然后提供可追溯的分析视图，最后把发现转成商品、渠道、促销和库存动作。
例如，我会要求一个“渠道贡献”指标同时说明销售额统计范围、退款处理时间、成本是否纳入、订单归属规则和数据刷新频率。这样业务人员在看到数字时，知道它能回答什么问题，也知道它不能被用于什么判断。
该流程为通用方法示例，具体连接方式、字段范围和权限应以实际系统评估为准。
以下数据为虚构的评估样本，用于展示如何把架构讨论转化为可比较的指标。分数越高表示风险越高，不代表任何真实项目结果。
示例中，“复制流程扩渠道”的短期交付速度看似较快，但随着渠道增多，规则重复、数据口径和回归风险同步上升；“模块边界加数据治理”前期需要投入更多设计时间，却能降低后续变化的传播范围。
我不会只看总分，而会追问：风险发生在哪个阶段？谁能发现？发现后多久能恢复？有没有保留渐进迁移的选择？数据可视化的价值，是让取舍变得可讨论，而不是用一个分数替代判断。
| 业务问题 | 需要的基础数据 | 容易出现的架构问题 | 建议动作 |
|---|---|---|---|
| 哪个渠道真正贡献利润？ | 订单、退款、商品成本、渠道费用 | 销售额在不同系统重复计算，成本缺失 | 建立指标定义与渠道归属规则，保留明细下钻 |
| 为什么某商品缺货？ | 库存、采购、仓配、销量预测 | 库存口径不同，预占和可售库存混淆 | 拆分库存状态，明确主数据和同步延迟 |
| 活动是否带来增量？ | 活动曝光、优惠、订单、复购 | 优惠规则与订单快照无法追溯 | 保存规则版本、命中原因和订单计算明细 |
| 退货率为何上升？ | 售后原因、商品批次、渠道、客服记录 | 售后原因是自由文本，无法聚合 | 建立标准原因树，同时保留补充描述 |
我会邀请产品、运营、客服、仓储、财务和研发共同列出未来半年最可能发生的变化：新增渠道、活动规则、区域仓、会员政策、结算周期、报表需求和权限变化。然后标记每个变化影响哪些数据、接口、页面和岗位。这个过程能让“架构难扩展”从抽象担忧变成具体传播路径。
实体回答“系统里有什么”，能力回答“能做什么”，规则回答“在什么条件下怎么做”，事件回答“发生了什么”。例如订单创建是业务事件，库存预占是库存能力，会员折扣是价格规则，不能把四者都塞进一个函数和一张表里。
不要只写“支持高并发”。我会把日订单量、峰值倍率、热点商品比例、消息积压容忍时间、报表刷新时效和后台任务窗口写成假设。假设不一定精确，但必须可验证。容量模型应当说明哪个资源先成为瓶颈，以及是否能独立扩展。
至少比较三种方案：继续在现有模块中实现、模块化重构后实现、拆出独立服务后实现。用同一组维度评估：交付周期、改动范围、数据一致性、可观测性、回滚难度、团队技能和未来扩展成本。不要因为方案图更复杂就认为它更专业。
可以选择一个新渠道、一个促销规则或一类报表作为试点，观察改动是否局部、数据是否可追溯、异常是否可恢复。上线后记录需求从提出到发布的周期、跨团队依赖数量、回归缺陷和运营自助率，用结果验证架构，而不是只看评审时的漂亮图。
建议每月复盘一次。完成度不是“架构先进度”，而是团队对关键变化的可控程度。
| 选择 | 适合场景 | 主要收益 | 主要代价 | 我的建议 |
|---|---|---|---|---|
| 模块化单体 | 团队较小、业务仍在验证、边界尚未稳定 | 交付快、调试简单、事务处理直接 | 边界容易被突破，需持续治理 | 先做模块边界、契约和测试，不要把单体当作随意堆代码 |
| 按领域拆服务 | 团队与业务边界稳定，部分模块有独立容量需求 | 可独立部署、扩展和负责 | 分布式事务、运维和排障复杂 | 从变化频繁且责任清楚的边界开始 |
| 事件驱动 | 跨域通知、异步处理、数据同步和最终一致场景 | 降低同步耦合，便于扩展消费者 | 重复、乱序、延迟和回放需要治理 | 先定义事件语义、幂等键、版本和补偿 |
| 规则配置化 | 促销、渠道、运费、会员权益等高频变化场景 | 减少发版，运营可自助调整 | 配置复杂、组合爆炸、错误风险上升 | 只配置高频变化项，保留校验、审批和模拟 |
| 数据平台治理 | 多渠道、多组织、多指标经营分析 | 统一口径，减少重复取数 | 建设周期和数据质量责任较重 | 从高价值指标与源头事件开始，避免万能大屏 |
我在做电商产品规划时，经常担心不用微服务会不会显得落后，也担心一开始拆得不够细，后面就无法扩展。我的理解是，微服务只是组织代码、部署和责任的一种方式，真正应该先回答业务边界是否稳定、团队是否能独立运维、服务之间是否有清晰契约。如果团队规模较小、业务还在验证，模块化单体可能更适合；当订单、库存、营销或渠道适配出现独立容量和独立发布需求时，再按变化边界渐进拆分，通常比一次性全面微服务化更稳妥。
我曾经把新增渠道理解成增加一个入口，后来发现渠道不仅带来页面，还会改变价格、库存、履约、佣金、售后、对账和数据归因。如果系统把渠道规则直接写进订单主流程，新增渠道就只能复制旧流程或增加大量条件分支。更好的做法是定义统一订单模型和渠道适配边界，把渠道差异封装在适配层，同时明确渠道订单映射、库存策略、价格规则、状态同步和对账责任，这样复用核心能力，隔离变化部分。
我对“万能促销引擎”一直比较谨慎，因为规则越灵活，组合数量和解释成本可能呈指数增加。满减、折扣、优惠券、赠品、会员价可以配置，但必须同时提供适用商品、渠道、用户范围、优先级、互斥关系、生效时间、试算结果和审计记录。比如一个订单为什么没有命中优惠，系统应展示资格校验失败的原因，而不是只返回最终金额。配置化的目标是隔离高频变化，不是让任何人都能随意改变核心交易逻辑。
我通常先把支付、履约、售后和订单生命周期拆开看，因为“已完成”在不同角色眼里可能代表不同事件。如果多个系统都能直接修改同一个 status 字段，就很难知道状态为什么变化，也无法可靠回放异常。产品经理应要求输出状态机：每个状态的含义、触发事件、前置条件、允许迁移、操作者、失败处理和通知对象。还要检查重复消息、乱序消息、人工修复和历史数据兼容，不能只看一张简单流程图。
我不会把共享数据库简单判定为绝对错误。项目早期，统一数据库可以减少重复建设，适合快速验证业务；真正危险的是没有读写责任、没有字段契约、没有迁移窗口，任何团队都可以直接改表和依赖内部字段。我的判断方式是看共享是否可控：谁拥有主数据，谁批准变更，跨域读取是否通过稳定视图或接口，字段是否有兼容周期，是否有数据质量监控。如果这些问题没有答案，共享数据库就会成为扩展和排障的主要阻力。
我会先区分实时强约束和异步通知。库存扣减、支付确认等环节可能需要严格的一致性或可验证的补偿；经营报表刷新、积分通知、用户标签更新、消息推送则通常允许延迟。如果一个业务事件需要被多个独立模块消费，并且不应该让主流程同步等待所有消费者，事件驱动就有价值。不过事件系统必须设计幂等键、事件版本、顺序要求、重试上限、死信处理、回放权限和监控指标，否则只是把同步问题转移成更难追踪的异步问题。
以本文的示例场景来说，E数通更适合作为经营数据连接、指标分析和决策协同的工具候选，而不是替代订单、库存或支付等核心交易系统。我的关注点是能否把多渠道数据按统一口径汇总，让业务人员查看销售、库存、商品和渠道表现时可以追溯到明细，并减少重复导数和手工拼表。具体是否适合，需要结合数据源、权限、刷新时效、指标复杂度和企业现有系统评估，本文不对任何未核实的实施结果作承诺。
我通常不建议因为架构问题就立即全面重写。重写会同时承担需求变化、历史数据迁移、隐性规则丢失和新旧系统并行的风险，项目可能几年都无法稳定交付。更可行的方式是先建立影响地图和监控基线，再选择一个边界清晰、收益明确的模块进行绞杀式迁移，例如渠道适配、报表查询或规则计算。通过接口隔离、事件同步、双写校验、灰度切流和可回滚方案逐步替换，只有在证据表明局部修复无法降低风险时，才考虑更大范围重构。
第一，电商系统的难扩展，本质是变化传播范围过大，而不单纯是代码量太多或服务数量太少。第二，产品经理应把扩展性写成可验证的业务问题：新增渠道需要改多少模块，新增规则需要多久发布，峰值流量能否局部扩容，指标能否追溯，故障能否补偿。第三，稳定能力与高频变化应该分离，订单、库存、支付等核心域要保持清晰责任，渠道、营销、分析等变化域要通过适配、规则、事件和数据治理承载变化。第四，数据平台和 E数通这类工具的价值，在于让经营分析从人工拼接走向统一口径和可追溯决策，但它不能替代业务系统的边界设计。
我最终会用一句话检验方案：当业务规模、渠道数量、规则复杂度或团队人数增加一倍时，系统是否能让变化局部发生、让资源按热点扩展、让责任清楚归属、让数据可解释、让故障可恢复。如果答案是否定的，就不要等到大促或组织扩张后再处理。
