单项目双组织场景下Basket calculation规则覆盖问题的架构方案咨询

可选架构方案 #

方案1：保留多套计算逻辑，实现组织维度路由（无代码迁移成本，隔离性最高） #

• 取消两套GrossCalculation实现直接注册到Component Framework的逻辑，改为仅注册一个全局路由型GrossCalculation入口，入口内部维护组织唯一标识与对应计算实现的映射关系
• 给每个组织的GrossCalculation实现类添加独立的@Qualifier标识，绑定对应组织ID，作为独立Bean注册到组件上下文，避免同名Bean覆盖
• 路由入口执行计算前，先从当前请求上下文读取所属组织的唯一标识，匹配到对应组织的计算实现后再执行对应逻辑
• 优势：两套计算逻辑仍保留在各自组织的cartridge中，无需迁移到公共组件，组织间逻辑完全隔离，迭代互不影响

方案2：收敛为单套通用计算逻辑，规则按组织动态匹配（减少重复代码，统一运维） #

• 将GrossCalculation核心骨架逻辑迁移到两个组织共用的通用cartridge中，抽象出规则扩展点，核心逻辑不与组织属性耦合
• 规则集新增组织维度的判断分支，执行前先拉取当前站点/组织的配置，加载对应组织的规则参数与分支逻辑
• 组织侧的自定义规则可通过扩展点注入，无需修改公共cartridge的核心代码
• 优势：无重复逻辑，核心计算逻辑迭代只需要修改一次，运维成本更低

选型建议 #

• 若两个组织的GrossCalculation逻辑差异度超过60%，且后续各自有独立的计算规则迭代需求，优先选方案1，隔离性更强，不会出现跨组织的逻辑影响
• 若两个组织的计算逻辑核心一致，仅存在参数、阈值、少量规则分支的差异，优先选方案2，避免冗余代码，统一迭代效率更高

注意事项 #

Salesforce Commerce Cloud Component Framework 默认会用后注册的同ID Bean覆盖先注册的Bean，无论选择哪种方案，都要避免给不同的计算实现类配置相同的Bean ID
组织标识统一从请求上下文的站点/组织配置中读取，禁止硬编码组织ID做判断

内容的提问来源于stack exchange，提问作者Karlo Sušanj