如何在OCC(commercewebservices)中合理使用自定义订单并解决依赖问题

作为常年跟Hybris打交道的开发者，这两个问题其实都是Hybris模块化设计里的常见坑，我给你梳理下最靠谱的解决方案：

你的核心诉求是避免代码复制，同时复用已有的自定义订单逻辑，最优方案是把共享业务逻辑抽离到独立的中间层扩展，具体步骤如下：

• 抽离共享逻辑到独立扩展
  把Storefront端和CommerceWebServices里和placeOrder相关的核心业务逻辑（比如自定义订单校验、特殊字段处理、工具类的核心功能）从原有扩展中剥离，放到一个独立的共享扩展里（比如命名为customorderfacades或customorderservices）。这个扩展要定位为通用的业务层组件，不依赖任何Storefront或WebServices的特定代码（比如不要引用accelerator的控制器类或者webservices的jax-rs注解）。

• 调整模块依赖关系
  在CommerceWebServices和OCC的extensioninfo.xml文件中，添加对这个共享扩展的依赖配置：

  <requires-extension name="customorderfacades"/>
  

  这样两个模块都能直接调用共享扩展里的服务和工具类，不用复制任何自定义代码。

• 重构原有代码
  在Storefront和CommerceWebServices的自定义控制器中，把原来的业务实现替换成调用共享扩展的服务方法，让原有模块只做请求转发和适配，核心逻辑都放在共享扩展里。

• 处理自定义扩展依赖
  如果原来的自定义代码依赖了其他扩展，把这些依赖也配置到共享扩展的extensioninfo.xml中，确保OCC只需要依赖共享扩展就能获取所有必要的依赖链。

这种方案完全符合Hybris的模块化设计原则，后续维护只需要修改共享扩展，所有依赖它的模块都会同步更新，彻底避免代码重复的问题。

这个矛盾其实是对“AddOn”定义的理解偏差，我给你理清楚：

Hybris官方文档称它为“特殊类型的AddOn”，是因为它提供了Storefront通用的基础组件（比如标签库、通用工具类、DTO）；而专家说它不是AddOn，是因为它不需要用ant addoninstall命令安装，没有传统AddOn的特定目录结构和安装脚本。

解决依赖问题的正确方式是：

• 直接添加扩展依赖：在OCC扩展的extensioninfo.xml里添加对它的依赖，不需要任何AddOn安装操作：

  <requires-extension name="acceleratorstorefrontcommons"/>
  

• 刷新依赖并构建：运行ant clean all让Hybris自动解析依赖，把acceleratorstorefrontcommons的类和资源引入到OCC的类路径中。

千万不要尝试用ant addoninstall来安装它，这会导致依赖解析错误，因为它本质上是一个通用的共享库扩展，而非可安装的Storefront AddOn。

内容的提问来源于stack exchange，提问作者Hatip Kabak