背景
作為丙方，完成了甲方的二開需求。因此，在設計二開模組的時候，考慮的是當時所列的需求清單，並整合到一個二開模組中。完成交付後，客戶評價蠻好的。因此，成功的為乙方爭取到了繼續合作的機會。然後，就沒我啥事了，尷尬...
再之後過了一兩個月，另一個丙方搞不定甲方的需求，所以我又被安排上線收拾殘局。而，此處接手的殘局有點坑，涉及多個開發的二開模組。由於甲方的需求是分批提出，且由多個團隊完成。因此，二開模組的間存在迴圈依賴的情況。在已經跑起來的庫上執行，沒有任何問題，但是，在新庫上重新安裝的時候，會發現根本安裝不上。因此，決定花一個月的時間徹底拆分已有的二開模組。
為什麼拆
問：一般情況下，odoo上線後基本上不會出現在新庫上重新部署的情況，為什麼還要費勁去拆分二開模組呢？
答：最核心的原因是，這可能是一個需要長期維護的專案。
問：長期維護的專案和單次分包的區別是什麼？
答：長期維護的專案，雖然在前期可能會付出更多的時間，但是可便於後期的專案管理，即便是最極端的情況發生，也可以以較快的速度恢復生產；而單次分包的專案，一般只是為了去完成一份需求清單，而且即使設計了二開的原因，也很少會有單次分包人員會遵守，因為工作量會增加。
怎麼拆
- 針對基礎模組的功能擴充套件：比如庫存、銷售、採購等，此類二開模組需僅包含針對該單一模組的功能擴充套件，且不能引用非odoo原生的模組；
- 針對多基礎模組的功能擴充套件：比如針對銷售的業務中擴充套件對調撥的業務處理邏輯，此類二開模組應僅包含odoo原生的基礎模組和1中二開模組；
- 針對獨立業務場景的功能擴充套件：比如圖書館有借書還書的需求，就需要單獨根據業務場景擴充套件功能模組。
以上三項是否拆分的合理的一個主要的標識是，1、2、3中的任意模組均可獨立安裝（2、3中在__manifest__.py中新增所需依賴）
本專案的拆分效果如下：
各二開模組建議是甲方公司的簡稱，便於標識。
結論
由於業務是不斷變化和發展的，為了讓系統真正成為助力業務發展的工具，勢必會接觸到odoo的二開市場。因此，不管是甲方還是可以長期維護的乙方，都建議在二開之初，可以參考上面提到的“怎麼拆”章節。當然，如果是單次分包，那就隨意吧。