背景
作为丙方，完成了甲方的二开需求。因此，在设计二开模块的时候，考虑的是当时所列的需求清单，并整合到一个二开模块中。完成交付后，客户评价蛮好的。因此，成功的为乙方争取到了继续合作的机会。然后，就没我啥事了，尴尬...
再之后过了一两个月，另一个丙方搞不定甲方的需求，所以我又被安排上线收拾残局。而，此处接手的残局有点坑，涉及多个开发的二开模块。由于甲方的需求是分批提出，且由多个团队完成。因此，二开模块的间存在循环依赖的情况。在已经跑起来的库上运行，没有任何问题，但是，在新库上重新安装的时候，会发现根本安装不上。因此，决定花一个月的时间彻底拆分已有的二开模块。
为什么拆
问：一般情况下，odoo上线后基本上不会出现在新库上重新部署的情况，为什么还要费劲去拆分二开模块呢？
答：最核心的原因是，这可能是一个需要长期维护的项目。
问：长期维护的项目和单次分包的区别是什么？
答：长期维护的项目，虽然在前期可能会付出更多的时间，但是可便于后期的项目管理，即便是最极端的情况发生，也可以以较快的速度恢复生产；而单次分包的项目，一般只是为了去完成一份需求清单，而且即使设计了二开的原因，也很少会有单次分包人员会遵守，因为工作量会增加。
怎么拆
- 针对基础模块的功能扩展：比如库存、销售、采购等，此类二开模块需仅包含针对该单一模块的功能扩展，且不能引用非odoo原生的模块；
- 针对多基础模块的功能扩展：比如针对销售的业务中扩展对调拨的业务处理逻辑，此类二开模块应仅包含odoo原生的基础模块和1中二开模块；
- 针对独立业务场景的功能扩展：比如图书馆有借书还书的需求，就需要单独根据业务场景扩展功能模块。
以上三项是否拆分的合理的一个主要的标识是，1、2、3中的任意模块均可独立安装（2、3中在__manifest__.py中添加所需依赖）
本项目的拆分效果如下：
各二开模块建议是甲方公司的简称，便于标识。
结论
由于业务是不断变化和发展的，为了让系统真正成为助力业务发展的工具，势必会接触到odoo的二开市场。因此，不管是甲方还是可以长期维护的乙方，都建议在二开之初，可以参考上面提到的“怎么拆”章节。当然，如果是单次分包，那就随意吧。