扩展业务还是改交易核心

怎样知道需求应该放在哪个位置？

从业务责任开始，而不是从方便修改的文件开始。先确定需求改变哪种规则、影响哪些对象和使用方，再查当前配置、用例与公开契约。若已有设置能够表达目标，优先核对正常配置路径；若是客户外部系统的差异，沟通适配边界；若必须改变交易共同规则，则明确核心修改和回归范围。

“扩展点”需要源码证据，不能泛指任何能加代码的位置。扩展平台基于源码定制（¥900 / 人天），需求确认后给固定总价。当前单体的业务装配事实为：当前单体在 单体应用 中装配 UMS、PMS、OMS、CMS；四域保留各自迁移与公开类型，共享单体数据源和本地事务管理器。 模块存在有助于组织职责，但是否能独立扩展某个行为仍要检查调用和数据约束。

配置已经满足需求时还需要开发吗？

先验证真实配置入口、适用范围、权限和生效方式。运营人员能够设置的字段，可能受到商城、门店或版本限制；不能只看界面上有相似名称就认为满足企业流程。通过合成资料检查正常保存、回读、修改与禁用，说明配置怎样影响最终业务结果。

若配置只覆盖部分需求，将缺口单独列出。不要为了展示一个完整方案而直接修改已有规则，也不要将新增代码隐藏在“配置调整”的范围中。配置记录和恢复方式也需要交接；能够配置不意味着不用验收，尤其是影响价格、渠道或权限的变化。

外部适配与核心规则怎么区分？

外部编号、字段名称、传输协议和状态映射通常属于系统协作问题，适配方应把外部数据转换成商城能够理解的明确业务操作。不得为了外部接口方便，将商城的金额、身份或成交状态改变为另一套含义。双方的数据权威来源仍应清楚，冲突和未知结果要能处理。

单体版仓库保留 OpenAPI 契约，管理端和 PC 端提供依据该契约生成接口类型的命令。 对接时先核对公开契约，再决定需要新增的入口。适配层不能绕过权限或直接写入别的业务域数据库来制造结果；如果确实缺少用例，需要把新增能力作为独立工程设计与验证。集成方法见系统集成专题，不要把存在契约等同客户连接器已完成。

模块扩展怎样保护调用方向？

新增业务先列公开输入、结果和错误，确定所属域和持久资料。调用其他域时使用其允许的边界，避免直接引用内部实体或读取私有表。模块职责应能由接口与测试解释，不只是将文件移到一个新目录。必要的共同规则还要明确由谁维护。

跨域数据关系需要记录识别方式和一致性责任。某个模块持有外部对象编号时，应说明对象失效、权限变化和历史保留如何处理。不要依靠前端组合多个管理接口来完成需要受控事务的业务动作。具体分层与新增模块方法见业务模块文档及分层说明。

哪些需求可能触及交易核心？

改变成交价格、退款分配、库存竞争、身份授权或订单状态，通常需要更广的语义检查。表面上只是增加一个条件，也可能影响报价、提交、支付、取消与售后。评审应画出受影响的完整路径，核对旧记录和调用方，并说明未覆盖场景。

金额以元为单位、使用精确十进制和接口字符串；积分、会员折扣与数量退款各有计算器，退款从冻结成交金额按累计数量差额分配。 核心修改要继续遵守已有金额单位和冻结规则，不能用二进制浮点或当前商品价格快速替换。若业务要求改变这些规则，先把目标不变量和迁移方式写清楚，再建立专门用例；“源码可改”不是跳过原有约束的理由。

三种候选方案怎样放在一起比较？

判断问题	已有配置或外围适配	模块新增	核心修改
业务含义	是否保持商城现有规则	是否有独立职责与公开输入	哪些共同不变量发生变化
权限范围	是否使用正常设置和业务入口	新权限及对象归属怎样检查	原权限和批量操作是否受影响
数据变化	是否只保存明确的映射资料	新数据归哪个域维护	旧记录怎样解释与迁移
验证范围	配置、接口和异常映射	正常、拒绝、关联失效	全链路、历史兼容和并发
升级影响	外部版本与配置兼容	模块公开边界与依赖	上游变化与定制差异重新评审

比较不是预先决定哪种方式更好，而是解释每种方式的代价和条件。若外围适配只能靠大量反向调用才能成立，可能需要正式新增业务用例；若模块职责仍依赖核心内部细节，也需要重新划分边界。用证据决定方案，不用“插件化”标签掩盖耦合。

接口、权限和错误需要怎样一起改？

新增操作应同步说明请求方法、身份、权限、数据范围、输入约束和可理解错误。不能只增加成功路径，再由前端猜测失败原因；调用方需要知道重试是否安全、冲突是否需要重新读取以及结果是否可查询。公开读取与管理操作的权限也应分别确认。

单体版存在账号类型声明、权限目录和业务审计声明；检查授权需同时核对请求方法、主体权限与业务数据范围。 修改既有入口时核对其所有使用方，避免管理端通过而PC或移动端不再兼容。接口类型生成与编译有助于发现字段变化，业务语义仍靠用例确认。更新的契约、实现和文档应对应同一版本，不能让运行团队依据旧说明操作新规则。

怎样记录升级时需要复查的改动？

为每项定制记录修改原因、所属规则、涉及文件、契约与结构变化以及验证资料。后续升级时先按业务目的比较差异，不只搜索同名文件。上游可能重构路径或改变默认行为，没有代码冲突也可能使定制失去原来的前提。

对容易受影响的规则建立可重复的业务用例，说明数据输入、期望结果和验证方法。交接时让新的开发者解释为什么采用当前方案，并尝试依据资料复查一次。这样可以避免长期依赖原实施者的记忆，也便于客户判断某项定制是否继续保留。

评审结束后应留下什么结论？

记录选择方式、理由、排除方案、代码与数据边界、权限、验收和升级影响。未知部分列调查条件，不直接合入正式版本。使用商城选型对比表汇总业务与技术约束，通过定制开发服务确认实现及交接范围。

回到商城二开专题安排预算、版本和运行协作，结合扩展开发说明核对已有能力。

临时绕过为什么不能成为扩展方案？

若方案依赖关闭权限校验、修改已有迁移或让前端直接写共享数据，应重新评审目标与位置。临时绕过会使当前演示看似可用，却改变其他入口的规则。记录遇到的约束及可行替代，由业务和技术共同决定新增用例或暂缓需求；不要让操作人员在交付后持续手工修补。