电商系统开发：产品经理自查表：系统架构最容易出现的架构难扩展
在电商系统开发中，最危险的信号不是“这个需求做不了”，而是“这个需求能做，但每次都要同时改商品表、价格逻辑、订单状态、库存接口和后台配置”。我在参与交易系统评审时，见过一个很典型的变化路径：系统最初只支持商品基础价和单仓库存，半年后增加会员价、渠道价、区域库存、预售和部分退款，结果一个看似普通的营销需求，影响了 6 个核心模块、18 个接口和 40 多条测试用例。系统并非没有功能，而是已经失去了吸收变化的能力。
这就是本文所说的“架构难扩展”：新增一种业务变化时，必须不断修改既有数据结构、核心状态和多个模块之间的隐性依赖。产品经理不需要先成为架构师，才有能力发现这类问题。只要在需求评审前检查变化落点、数据归属、历史快照、异常分支和模块影响范围，就能提前识别大部分返工风险。
我通常会在评审会上先问一句：“如果下个月再增加一种相似规则，研发需要修改哪些地方？”这比直接问“系统是否具备扩展性”有效得多。后者容易得到“已经模块化”“支持配置化”等概念性回答，前者却会迫使团队列出真实的数据库、接口、状态和测试影响。
如果新增一个价格类型只需要增加一条配置，并且价格计算、订单快照、退款核算都能复用既有能力，说明系统至少在这个变化方向上有一定弹性。反过来，如果新增一个价格类型需要增加字段、扩展枚举、修改多个分支判断，还要重新处理历史订单，那么问题就不再是单一需求复杂，而是架构已经把变化写死了。
这五类信号有一个共同点：它们都能从产品文档和接口评审中被发现，而不需要产品经理阅读源码。产品经理真正要做的，不是替研发决定采用哪一种技术，而是把“未来会变化的业务对象”和“必须保持不变的交易结果”区分开。
很多系统在架构介绍中会写“支持灵活配置”，但我会继续追问三个问题：配置谁负责？配置何时生效？配置产生的结果能否追溯？如果运营可以随时修改促销规则，但订单没有保存计算明细，系统只是把代码里的问题换成了配置后台的问题。
可扩展性至少包含三层含义。第一层是新增能力时不必反复改核心数据结构；第二层是规则变化不会破坏历史交易；第三层是异常发生后能够查询、重试、补偿和对账。只做到第一层，系统可能看起来灵活，但仍然会在退款、售后和财务核算阶段暴露问题。
电商系统的难点不只是订单量，而是同一个业务对象会被不断赋予新的条件。一个商品可能先按单一价格销售，后来增加会员价、渠道价和阶梯价；一个库存可能先按总量管理，后来拆成仓库库存、区域库存、预售库存和锁定库存；一个订单可能先支持整单发货，后来又出现拆单、部分退款和售后换货。
这类变化有一个明显特征：需求表面上是在增加“一个选项”，底层实际上是在增加一个新的业务维度。产品经理如果只在页面上增加下拉框，系统可能会把这个维度偷偷挤进原有字段、枚举或条件判断中，最终形成无法解释的例外逻辑。
例如，需求文档中出现“商品价格”四个字时，我不会立即接受这个字段定义，而会追问它究竟指什么。它可能是前台展示价、会员可见价、促销前基础价，也可能是订单成交价。四者看起来都叫价格，但生命周期、数据来源和修改权限完全不同。
前台展示价可以随活动变化，订单成交价却必须在交易完成后保持可追溯；商品基础价属于商品或定价域，优惠金额来自营销计算，支付金额属于订单交易结果。若把这些值全部塞入一个字段，短期查询很方便，长期却会出现“页面显示对了、退款算错了、财务对不上”的问题。
我见过不少系统在第一次增加会员价时完全没有问题，因为开发直接加了一个字段。真正的问题发生在第二次和第三次：渠道价继续加字段，活动价再加字段，区域价又加字段，随后研发开始在代码中写“如果是会员且来自某渠道且处于活动时间，则优先取某个字段”。
单次改动的成本可能只有几个人天，但连续改动会形成复合成本。字段越多，接口越难理解；条件越多，测试组合越大；历史数据越不统一，迁移和回溯越困难。架构难扩展往往不是某个设计瞬间失败，而是许多“先加一个字段”“先写一个判断”叠加后的结果。
产品经理容易从页面模块判断系统边界：商品页、订单页、营销页、库存页各自独立。但系统真正的耦合点通常藏在数据和规则里。页面上只是多一个“区域价”选项，后台可能需要新增区域维度，价格服务需要改变匹配逻辑，订单需要保存命中的规则，结算又需要理解优惠分摊。
因此，需求评审不能只看页面原型。至少还要同时看一张业务对象关系图、一张状态流转图和一张数据快照说明。页面负责解释用户怎么操作，架构影响评估则要解释操作之后哪些数据会变化、谁拥有这些数据、失败时如何恢复。
加字段并非绝对错误。对于稳定、明确、查询频繁的属性，例如商品编码、重量或基础税率，固定字段通常更容易理解，也更便于查询和校验。问题出在把高频变化的业务规则也当作固定属性处理。
当产品经理发现每新增一种价格就要加一个字段，或者每新增一种渠道就要在多张表中复制渠道字段时，应该停下来判断：这究竟是一个稳定属性，还是一个会持续扩展的业务集合。前者可以保持固定结构，后者至少要重新梳理实体、维度、生效时间和规则优先级。
订单表是最容易膨胀的表。商品、优惠、支付、配送、分账、售后、发票和风控都可能希望往里面增加字段。刚开始这样做很方便，因为查询入口统一；但订单表一旦承载了所有业务含义，任何一个领域的变化都会影响交易主链路。
我在评审订单设计时，会把字段分成三类：交易必须保留的快照、订单自身的状态和金额、其他领域的关联引用。商品详情不必把全部动态属性复制到订单，但成交时的商品名称、规格、单价和优惠结果必须具备可追溯性。售后审核信息、仓库操作记录和支付渠道流水，也不应全部挤进同一张订单主表。
一个“订单状态”字段看起来简单，却经常同时表达支付状态、履约状态、售后状态和结算状态。于是系统会出现“已完成但退款中”“已发货但部分售后”“支付成功但库存处理中”等无法用单一枚举准确描述的情况。
更稳妥的做法是先识别不同状态维度。例如，支付状态可以包括待支付、支付处理中、已支付和支付失败；履约状态可以包括待配货、部分发货、已发货和已签收；售后状态则另行管理。并非每个系统都必须拆成多个微服务，但产品文档必须先把这些状态语义分开。
规则引擎能减少代码发布，但不能自动减少业务复杂度。如果规则后台允许任意字段互相组合，却没有版本、优先级、模拟运行、审批和回滚能力，运营人员可能配置出开发都无法解释的结果。
我更倾向于采用“有限配置化”：先定义允许变化的条件、动作和优先级，再提供可验证的配置范围。对于金额计算、优惠叠加和库存扣减，必须能够记录命中了哪些规则、使用了哪个版本、最终产生了什么结果。灵活性不能以可审计性和可测试性为代价。
如果商品、订单、库存和营销之间的数据归属没有厘清，拆成多个服务只会把本地耦合变成远程调用。一次下单需要连续调用多个服务，任何超时、重复消息或部分成功都可能形成新的故障链。
扩展性首先是业务边界清楚、数据责任明确、失败路径可处理，其次才是部署单元是否拆分。一个边界清晰的单体系统，可能比多个互相读库、互相依赖的服务更容易维护。
我会把需求中的名词圈出来，再标记它们是否存在“多种、多级、多个来源、按条件变化、按时间生效”这五类特征。商品有多个规格，价格有多个来源，库存有多个仓库，订单有多个履约节点，这些词一旦出现，就说明系统可能需要承接新的业务维度。
维度本身不是问题，未被明确建模的维度才是问题。产品经理应该继续追问：这个维度由谁维护？是否影响交易？是否需要历史保留？是否参与查询？是否有优先级？如果五个问题都没有答案，需求还不能直接进入开发排期。
这是我认为最有价值的一组判断。配置是人可以调整的参数，例如某会员等级的折扣比例；规则是系统基于多个条件进行计算的过程，例如满足满减门槛后减免金额；结果是一次具体交易最终确定的价格、优惠和应付金额。
配置可以变化，规则可以版本化，结果必须可追溯。若订单页面每次都根据当前配置重新计算历史优惠，就会出现订单金额随活动变化的问题。若系统只保存最终应付金额而没有保存优惠明细，退款和财务复核又会缺少依据。
配置：会员等级 = 黄金，折扣 = 95%
规则：用户等级 + 商品范围 + 生效时间 → 计算优惠
结果：订单号 10001，原价 100 元，优惠 5 元，成交价 95 元
新增业务如果只影响一个模块，通常可以按普通迭代处理；如果需要跨越商品、营销、订单、库存和结算多个领域，就必须讨论数据同步、失败补偿和回滚策略。这里的重点不是模块数量越多越不好，而是跨越边界后，谁负责最终结果必须清楚。
例如，营销模块可以计算优惠建议，但订单模块必须确认最终成交金额；库存模块可以返回锁定结果，但订单模块必须根据结果推进状态；支付渠道可以返回支付通知，但订单系统必须处理重复通知和通知乱序。边界越多，产品需求中的失败状态就越不能省略。
凡是涉及金额、商品规格、收货地址、税费、优惠、结算和履约的字段，我都会默认它们可能需要历史快照，直到业务方明确说不需要。因为用户看到的历史订单、客服处理的售后单和财务核对的结算单，依据的不是今天的商品数据，而是交易发生时的事实。
快照并不意味着把整个商品对象复制一遍。应当根据售后、审计和对账需求，确定哪些字段必须冻结，哪些字段可以通过引用实时查询。这个边界需要业务、产品、研发和财务共同确认，不能只由数据库设计者决定。
第一次新增规则时，直接迭代往往最经济；第二次新增相似规则时，应该记录前后两次需求的共同结构；第三次新增时，就有足够证据判断哪些部分是稳定模式，哪些部分只是偶然特例。
我不建议需求第一次出现就设计一个极其通用的模型，也不建议连续三次出现同类变化后仍然复制字段。第三次变化是一个实用的决策节点：它能避免过度设计，也能避免团队在明显重复的返工中继续消耗。
下面这个案例是我按常见电商项目整理的样本，不对应某一家企业的真实内部数据。系统初期销售标准化商品，业务规则很简单：一个商品有多个 SKU，每个 SKU 一个销售价，一个总库存，订单整单支付、整单发货、整单完成。
在这个阶段，采用商品表、SKU 表、订单表和库存表的简化设计并不一定错误。因为业务变化少，固定字段带来的查询效率和开发效率都很有价值。问题不在于系统起点简单，而在于团队没有记录哪些设计只适用于当前阶段。
产品提出会员价后，团队在 SKU 表中增加会员价字段，并在商品详情页和下单接口中增加判断。这个方案上线很快，页面也能正确展示，但需求文档没有明确会员价是否与活动价叠加、会员价何时生效、订单取消后是否按会员价退款。
如果会员价只是固定折扣，且不与其他优惠叠加，新增字段可以暂时接受。产品经理应当在评审记录中写清楚这个边界，而不是让研发默认“以后可能会支持更多价格”。明确不支持什么，同样是架构设计的一部分。
当渠道和区域同时出现后，固定字段开始显出问题。系统可能需要把价格理解为“SKU、渠道、区域、会员等级、时间范围”的组合，而不是 SKU 上的几个平行字段。此时继续增加 channel_price、region_price 等字段，并不能表达两个维度同时命中的情况。
更合理的建模方向，是把价格视为具有条件和生效范围的记录，并明确匹配优先级。这里不等于必须马上引入复杂规则引擎，而是至少要在产品层面确认：一个订单命中多个价格时如何选择，未来价格是否支持预约生效，价格调整是否需要保留版本。
活动价和优惠券加入后，系统不再只是“查询一个价格”，而是要执行一套计算流程。商品基础价、渠道价、会员价、活动价、优惠券和运费可能分别来自不同模块。若订单只保存一个最终金额，售后人员无法判断优惠如何分摊，财务也很难解释部分退款的金额。
我建议至少保留以下交易明细：商品原价、命中的价格类型、优惠金额、优惠来源、优惠分摊结果、运费、税费和最终应付金额。是否保存完整规则输入，要结合系统审计要求决定，但最终结果和主要计算依据不能只存在于实时服务的日志里。
当系统增加预售、分仓或渠道库存后，“库存”这个词已经不够准确。用户看到的是可售库存，仓库管理的是物理库存，订单系统需要的是锁定库存，供应链关注的可能是在途库存。四者如果共用一个字段，扣减、释放和补货都容易出现口径冲突。
产品经理在需求中至少要标明库存动作发生的时点：下单锁定、支付扣减、取消释放，还是支付成功后才锁定。还要明确超时订单、支付失败、重复回调和人工取消分别如何处理。库存问题经常不是算法复杂，而是业务时点没有写清楚。
拆单发货和部分退款会直接挑战“一个订单一个状态”的设计。订单可能已经部分发货，但仍有商品待配货；一部分商品完成售后，另一部分商品正常收货。如果系统只有待支付、已支付、已发货、已完成几个状态，产品只能不断增加特殊状态，开发则会在每个状态判断中加入例外。
这时需要把订单、订单行、支付、履约和售后分别看待。订单行可以有自己的发货和售后状态，订单主状态则根据子项汇总。是否采用事件驱动或拆分服务不是第一决策，第一决策是把“一个订单中可能存在多个不同进度”写进业务模型。
架构评审不应只依赖“大家觉得以后会复杂”。我会建议团队连续记录三类数据：相似需求平均改动模块数、需求从开发到上线的回归测试用例增长、线上人工补偿和数据修复次数。这些指标不能直接证明某种技术方案更好，但能帮助团队识别变化成本是否正在上升。
例如，某类价格需求连续三个迭代的影响模块数分别是 2、4、6，回归测试用例从 12 条增加到 37 条，人工修复从 0 次增加到每月 5 次，这就比一句“价格模块不够灵活”更有说服力。数据来源可以是需求单、代码评审记录、测试报告和线上工单，不必编造所谓行业平均值。
商品通常描述销售对象，SKU 描述可交易的具体规格组合。商品名称、品牌、详情和类目可能属于商品层，颜色、容量、尺码和条码通常属于 SKU 层，价格和库存也往往以 SKU 为主要交易单位。
产品经理可以用下面的问题检查商品模型：
如果新增一个类目属性就要修改数据库、接口、后台表单和搜索索引，说明属性模型可能过于固定。但也不要把所有属性都做成完全动态的键值结构，否则筛选、校验、统计和性能都会变得复杂。实际项目中，固定核心属性与可配置扩展属性结合，往往比单一方案更稳妥。
价格架构最重要的不是能返回一个数字，而是能说明这个数字如何产生。产品文档应当列出价格来源、命中条件、优先级、生效时间、叠加关系和订单保存方式。
| 检查方向 | 需要回答的问题 | 高风险表现 | 产品动作 |
|---|---|---|---|
| 价格来源 | 基础价、会员价、渠道价分别由谁维护？ | 多个模块都能修改同一价格 | 明确唯一数据归属 |
| 优先级 | 多个价格同时命中时如何选择？ | 依靠代码中隐藏的先后顺序 | 在需求中写出优先级矩阵 |
| 生效时间 | 未来价格能否预约？修改后旧订单是否受影响？ | 实时配置覆盖历史结果 | 增加生效版本和交易快照 |
| 优惠分摊 | 整单优惠如何分摊到商品行？ | 部分退款金额无法解释 | 明确分摊算法和舍入规则 |
| 审计追溯 | 能否还原某订单当时命中的规则？ | 只能查当前配置或日志 | 保存规则版本和计算明细 |
库存需求中最容易出现的模糊词是“库存不足”。不足的是物理库存、可售库存、某个仓库的库存，还是某个渠道分配额度？如果产品经理没有定义口径，研发只能根据当前流程猜测，后续换仓、预售或渠道限售时就会出现冲突。
建议在需求中单独列出库存状态和动作：
如果产品文档只写“下单后扣减库存”，信息远远不够。至少要补充动作时点、失败状态和人工处理入口，否则上线后最容易出现的是库存账面与订单事实不一致。
订单状态设计建议从“订单主状态、支付状态、履约状态、售后状态、结算状态”几个维度分别梳理。并非所有项目都需要将它们做成独立表或独立服务，但每个状态的含义、触发条件和允许动作必须能单独解释。
尤其要检查以下场景：
这些场景不是“测试阶段再补”的细节，而是状态模型的一部分。如果它们没有在需求阶段出现，系统通常会用人工备注、临时字段或后台按钮来兜底，最终形成不可复用的特殊流程。
产品经理不必设计全部接口版本，但必须在需求中提出兼容问题。新增字段是否必填？旧客户端是否能忽略？枚举增加后，旧调用方是否会因为未知值报错？接口返回的数据是展示用途还是交易用途？这些问题会直接影响上线方式。
如果核心接口被多个前端、报表、外部渠道和内部服务使用，建议采用兼容性清单：
如果一个业务规则已经稳定多年，变化范围明确，只影响一个模块，且没有明显的多维组合需求，产品经理不必为了追求“未来无限扩展”而引入复杂模型。固定字段、明确接口和完整测试，可能是更好的选择。
这种情况下，建议保留三项记录：当前方案的适用边界、未来触发重构的信号、历史数据是否需要快照。这样做的价值在于，团队知道什么时候可以继续加功能，什么时候必须重新评估，而不是把临时方案误认为永久架构。
当会员价、渠道价和区域价连续出现时，产品经理应推动一次共同结构梳理。重点不是马上确定表结构，而是找出它们共同拥有的属性：适用对象、条件、优先级、有效期、来源、审批状态和版本。
如果这些规则未来由运营频繁调整，可以考虑配置化；如果规则组合已经复杂到需要回放和审计，则要增加计算记录；如果规则仍处于探索期，先保留清晰的代码逻辑也可能更稳妥。抽象应当来自重复变化，而不是来自技术偏好。
当交易链路出现跨服务调用时，我会把“失败时怎么办”放在“正常时怎么走”之前。支付成功、库存失败，库存成功、订单写入失败，消息重复、请求超时、回调乱序，这些场景决定系统是否可运营。
产品经理可以推动研发明确以下内容：
如果系统已经存在很多以 temp、new、flag 或特殊业务名称命名的字段，不要继续无边界地往上叠加。第一步可以是建立字段字典，记录字段含义、写入方、读取方、上线时间和是否仍在使用。
第二步是找出影响交易结果的字段，优先补齐快照、版本和审计；第三步才是评估是否需要迁移数据或拆分模型。存量系统重构最忌讳一次性推翻全部结构，应该先保护订单、支付、库存和结算这些不可轻易出错的链路。
创业期或新业务早期经常需要快速验证价格、促销和履约方式。此时过早设计复杂的通用模型，可能拖慢验证速度。我的建议是：允许实现简单，但要保证订单结果、关键输入和变更记录可追溯。
例如，促销规则可以先用明确的代码逻辑实现，但订单必须保存原价、优惠和最终应付金额；渠道库存可以先采用有限的库存分配方案，但要明确库存口径和异常处理。简单方案可以被替换，无法解释的历史交易却很难补救。
固定结构的优势是简单、可读、性能可预测，适合业务稳定、查询明确、规则数量少的场景。它的缺点是每次扩展都可能修改表结构、接口和代码分支，尤其不适合价格、促销和状态持续变化的系统。
| 适用条件 | 主要优势 | 主要风险 | 产品经理应关注什么 |
|---|---|---|---|
| 规则少且长期稳定 | 实现和排错简单 | 变化时需要改代码和结构 | 记录未来变化触发条件 |
| 核心字段查询频繁 | 查询效率和数据校验较好 | 字段语义容易被滥用 | 保证字段只表达一种含义 |
| 业务处于快速验证期 | 上线速度快 | 临时方案可能长期化 | 保留快照、日志和迁移路径 |
配置化适合规则变化频繁、运营人员需要参与调整、业务条件相对结构化的场景。它能减少频繁发布代码的需求，但会增加配置校验、权限、审批、生效、回滚和监控的建设成本。
配置化最容易失败的地方，是只做了“新增配置项”，没有做配置生命周期。一个完整的配置至少要考虑草稿、审核、发布、生效、停用、回滚和操作记录。对于金额和库存相关配置，还需要预览计算结果和模拟命中情况。
规则引擎适合规则组合复杂、条件和动作具有重复结构、并且业务方需要频繁调整的场景。但它不适合所有系统。若业务规则只有两三个固定判断，引入规则引擎可能让排错变得更困难。
我会从四个维度判断是否值得引入：
如果四项中只有第一项成立，通常还不足以证明需要规则引擎。先提炼业务边界和规则接口，往往比直接引入平台更稳妥。
商品属性设计也存在类似取舍。固定字段适合核心检索、排序、校验和统计；动态属性适合类目差异大、运营配置多、变化频率高的场景。完全固定会导致不断改表，完全动态则会让查询、索引和数据质量变差。
实践中可以采用分层方式：将商品编码、品牌、类目、重量等核心属性固定下来；将材质、适用场景、包装方式等类目差异较大的属性做成可配置集合；对参与价格、库存或交易校验的属性，仍然保留结构化字段或明确索引。
需求立项阶段不要急着写完整页面，而应先回答本次变化会影响哪些业务对象。可以用“对象，变化，结果”的方式记录：商品增加一个规格，价格需要重新匹配，库存需要独立扣减，订单需要保存规格快照。
变化地图不需要很复杂，一张表就够：
| 业务对象 | 本次变化 | 是否影响交易 | 是否需要历史保留 | 责任模块 |
|---|---|---|---|---|
| SKU | 增加销售规格 | 是 | 是 | 商品域 |
| 价格 | 增加区域条件 | 是 | 是 | 定价域 |
| 库存 | 按仓库拆分 | 是 | 需保留流水 | 库存域 |
| 订单 | 支持部分发货 | 是 | 是 | 交易域 |
这十个问题的目的不是让产品经理替代技术方案，而是避免需求文档只描述“用户点击什么”。如果这些问题中有三项以上无法回答，我通常会建议把需求从普通功能评审升级为架构影响评审。
研发方案确定后，产品经理要关注影响范围是否与需求表面复杂度匹配。如果需求只是增加一个后台配置，却需要修改订单、结算和库存，那么必须知道原因：是业务确实跨域，还是系统存在不必要的耦合。
测试范围也应按业务结果组织，而不是只按页面组织。增加一个价格规则，至少要覆盖正常下单、失效时间、重复命中、优惠叠加、取消、退款和历史订单展示。这样才能发现“页面新增成功，但交易闭环不完整”的问题。
架构调整是否有效，不能只看是否成功上线。上线后建议观察四类指标：相似需求平均改动模块数、回归测试耗时、线上数据修复次数、人工客服或运营介入次数。
如果新增规则后，配置时间减少了，但异常订单和人工修复增加，说明系统只是把成本从开发端转移到了运营端。真正有效的扩展应当同时降低重复开发成本，并保持交易结果可解释、可恢复和可对账。
如果以下问题出现“是”，建议在排期前发起架构影响评估：
| 检查项 | 是 | 否 | 判断依据 |
|---|---|---|---|
| 新增一种规则是否需要修改三个以上核心模块 | □ | □ | 跨模块影响范围过大 |
| 价格、库存或订单结果是否依赖实时配置重新计算 | □ | □ | 历史交易可能无法还原 |
| 订单是否只有一个状态字段承载多个流程 | □ | □ | 部分履约和逆向流程难以表达 |
| 多个模块是否直接读写同一张核心业务表 | □ | □ | 数据归属不清，改表容易引发连锁故障 |
| 新增枚举值是否可能让旧调用方报错 | □ | □ | 接口兼容策略不足 |
| 支付、库存和订单是否存在部分成功状态 | □ | □ | 需要幂等、重试和补偿机制 |
| 同类需求是否已经连续出现三次 | □ | □ | 已有足够证据提炼共同结构 |
| 系统是否依赖大量临时字段、特殊状态和人工备注 | □ | □ | 说明架构债务正在显性化 |
中风险并不意味着必须重构，而是意味着产品经理不能只写主流程。至少要在需求文档中增加边界条件、数据归属和历史兼容说明。
低风险需求也需要测试，但不必用复杂架构方案处理。一个成熟团队的能力，不是把所有需求都升级成大项目，而是知道哪些问题值得抽象、哪些问题保持简单更好。
电商系统开发中，产品经理判断架构是否难扩展，最终可以归纳为三个问题：新增变化会落在哪个业务领域？历史数据是否需要保持原样？这次改动是否会迫使多个核心模块同时修改？如果三个问题都没有明确答案，需求就不应只按照普通功能迭代处理。
我不认为所有电商系统都应该采用微服务、动态模型或规则引擎。架构方案必须服从业务变化频率、团队维护能力、交易风险和数据规模。固定结构可以很优秀，配置化也可能失控，复杂方案并不天然比简单方案更专业。
真正有价值的架构自查，不是提前猜中未来所有需求，而是让团队在变化出现时知道该保护什么、该抽象什么、该拒绝什么。系统是否可扩展，最终不体现在技术名词有多先进，而体现在新增业务规则时，历史交易仍然可信，模块边界仍然清楚，失败结果仍然可以恢复。
如果产品经理能在需求评审前持续追问“这次变化会改变哪个事实、由谁负责这个事实、未来如何解释这个事实”，就已经完成了架构治理中最难、也最有价值的一步。
我经常遇到这样的情况：需求文档看起来只是新增一个价格类型、一个订单状态，研发评估却说要同时修改商品、购物车、订单、库存和报表模块。我想知道，产品经理不深入阅读代码，只看需求、流程和数据模型，能不能提前判断这种风险？
可以。我的判断方法不是先问系统用了微服务还是单体，而是追踪“一个变化会穿过多少个边界”。如果新增一种业务规则，必须同时修改多个核心表、多个接口和多个状态流转，通常说明系统扩展点没有被隔离。我在评审需求时会画一条最短影响链。
例如“新增直播专属价”，至少要追踪：价格来源、商品详情展示、购物车重算、下单校验、订单快照、退款金额和财务对账。如果这条链路上每个模块都通过新增字段或硬编码判断来适配，风险就不是一个普通功能点，而是价格模型正在失控。
评审信号低风险表现高风险表现 新增规则影响范围主要修改一个领域模块商品、订单、库存、报表同时修改 数据表达方式规则、结果和历史快照分开所有信息都塞进核心业务表 状态变化状态流转有明确前置条件到处增加if判断和特殊状态 历史数据能还原当时的交易结果依赖当前商品和促销配置重新计算 我建议产品经理在评审前固定问三个问题：第一，这个变化属于哪个业务领域；
第二，成交后哪些数据必须保持不变；第三，新增规则是否会迫使无关模块一起修改。只要其中两个问题答不清楚，就应该增加架构影响评估，而不是直接进入开发排期。
我现在的系统早期只支持单规格商品，所以商品表里直接放了价格、库存和条码。后来要增加颜色、尺寸、会员价、渠道价和区域库存，数据库字段越来越多，我不确定这是继续加字段，还是应该重新设计商品和SKU模型。
真正容易出问题的，不是商品表字段多，而是把不同生命周期、不同归属的数据硬塞在同一层。商品名称、详情和品牌通常是商品信息；颜色、尺寸、容量等组合后形成销售规格；价格、库存和条码则往往属于可销售的SKU。它们变化频率不同，却经常被设计成一张表里的并列字段。
我处理这类模型时，会先用一个简单关系检查：一个商品是否可能有多个SKU，一个SKU是否可能有多个价格记录，一个SKU是否可能对应多个仓库库存。如果答案都是“是”，却仍然只有一张商品表和几个固定字段，后续扩展大概率会依赖不断加字段。
对象更适合承载的内容常见错误 商品或SPU名称、品牌、详情、类目直接承载所有规格库存 SKU规格组合、条码、可销售标识把颜色和尺寸拆成固定列且无法扩展 价格记录价格类型、生效时间、适用范围不断增加普通价、会员价、活动价字段 库存记录仓库、渠道、可用量、锁定量只保留一个库存数字 不过，我不建议为了追求灵活，立刻把所有属性改成动态键值结构。
稳定且高频查询的核心属性保留明确字段通常更容易维护；只有当属性持续增加、类目差异明显，并且后台需要配置时，才值得引入可配置属性模型。产品经理要重点确认的不是“能不能加字段”，而是这个字段未来是否会出现多个值、多个适用范围和多个生效时间。价格尤其要保存成交快照。
商品当前显示的价格可以变化，但订单中的成交单价、优惠金额和应付金额不能依赖用户再次打开订单时的实时规则，否则改价或活动结束后，历史订单、退款和对账都会出现不一致。
我在画电商流程图时，通常只写待支付、已支付、已发货和已完成，但研发经常追问支付处理中、部分发货、库存释放失败和部分退款。我想知道，哪些异常状态必须在产品阶段明确，哪些可以交给技术兜底？
订单系统最危险的地方，是把“正常流程”误当成“完整流程”。支付成功、库存扣减和订单状态更新并不一定在同一瞬间完成，网络超时、重复回调、部分发货和售后逆向流程都会制造中间状态。若产品文档没有定义这些状态，开发通常只能把异常压缩成失败或成功，后续一旦增加分仓、拆单和部分退款，就会被迫重写状态逻辑。
我会把订单拆成业务事实和处理状态，而不是只维护一个巨大的订单状态枚举。例如支付结果、库存结果、履约结果和售后结果分别记录，再由订单聚合状态展示给用户。这样“支付成功但库存不足”可以进入待人工处理或自动退款，而不必伪装成一个含义模糊的“异常订单”。
场景产品必须定义的结果未定义时的典型后果 支付回调重复到达只允许一次有效入账，接口可幂等重复加款或重复推进订单 支付成功但扣库存超时查询、重试、补偿和退款路径用户已付款但订单无法履约 订单部分发货子包裹、子项状态和部分售后规则整单状态无法准确表达 取消时库存释放失败释放重试和库存对账机制可用库存长期被锁定 部分退款退款金额、商品项和优惠分摊口径退款金额与财务账不一致 一个实用的自查方法是给每条状态流转补三个问题：谁触发、失败后停在哪里、重复触发会不会产生第二次结果。
比如“支付成功”不能只写成状态变化，还要说明回调幂等、订单金额校验和库存处理失败时的补偿动作。库存也不要只保留一个“库存数”。至少要区分物理库存、可用库存和锁定库存；如果存在预售、分仓或渠道销售，还要明确这些库存是否共享。
产品经理不需要决定具体表结构，但必须先确定每种库存数字的业务口径，否则技术再怎么优化也无法消除争议。
我担心团队一听到扩展性问题就建议微服务、规则引擎或重构，但项目预算和交付周期都有限。有些需求可能只是临时活动，另一些需求却会反复出现，我想用一套更客观的方法判断到底该不该动架构。
我不把“是否使用微服务”作为重构起点，而是看变化是否已经形成稳定模式。一次性的业务差异可以用局部适配解决；同一类规则连续出现，且每次都要修改多个核心模块，就说明系统需要抽象。架构改造的触发条件应该来自变化频率和影响范围，而不是技术潮流。
我会用一个简单的风险评分做初筛：变化频率、影响模块数、历史数据敏感度和异常处理复杂度，各按1到3分评估。总分在4到6分时通常可以局部迭代；达到7到9分，应先补边界和兼容方案；达到10分以上，建议把架构改造纳入需求，而不是继续堆补丁。这个分数不是行业标准，但能帮助产品、研发和管理者用同一套语言讨论。
判断维度可继续迭代应考虑重构或抽象 变化频率规则稳定，偶尔调整同类规则连续新增 影响范围单一模块可独立完成每次都牵动多个核心模块 历史数据旧数据不受影响订单、退款和对账必须还原历史规则 配置复杂度少量参数即可表达配置组合已接近编程，难以测试 故障处理失败可重试且边界清楚异常依赖人工查库和临时修数据 有一个常被忽视的信号：如果需求评审中频繁出现“先加一个特殊判断”“只对这个渠道生效”“历史订单不用管”，说明系统正在积累不可见的分支。
短期看它比重构快，长期却会让测试范围、数据迁移和售后解释成本同步增加。我通常建议先做边界重构，而不是一次性推翻系统。比如先把订单成交快照补齐，再隔离价格计算结果；先统一库存锁定、扣减和释放接口，再考虑拆分库存服务。
这样每一步都有可验证的业务收益，也能避免为了追求“先进架构”而引入过度配置、分布式事务和运维复杂度。
读者评论
文章把“架构难扩展”从技术概念落到了产品评审场景，尤其是价格、库存、订单状态不断增加后的连锁影响，比较有参考价值。对产品经理来说，先梳理变化落点和历史快照，确实比直接讨论是否微服务更实际。
关于“可配置不等于可扩展”的分析比较到位。配置版本、命中规则和历史结果如果无法追溯，后续退款、对账和售后都会受影响。不过文中的组合数量属于情景推演，实际项目还需结合业务规模验证。
订单快照、状态拆分和异常补偿是容易被忽略的部分，文章提醒得很实用。个人认为，系统是否需要规则引擎或服务拆分，仍应根据团队能力、业务复杂度和故障处理能力综合判断，不能只看架构形式。