[發明專利]一種平臺插件化軟件研發構架及其設計方法、系統

在審

• 申請號: 202010418546.4
• 申請日: 2020-05-18
• 公開（公告）號: CN111752537A
• 公開（公告）日: 2020-10-09
• 發明（設計）人: 王義哲
• 申請（專利權）人: 蘇州浪潮智能科技有限公司
• 主分類號: G06F8/20
• 分類號: G06F8/20
• 代理公司: 濟南誠智商標專利事務所有限公司 37105
• 代理人: 黃曉燕

本發明涉及軟件開發設計技術領域，提供一種平臺插件化軟件研發構架及其設計方法、系統，平臺插件化軟件研發構架包括獨立平臺數據庫LEGO、軟件研發包和若干個功能自治包；其中，所述獨立平臺數據庫LEGO包含有表征其功能的標識，所述軟件研發包表征所述獨立平臺數據庫LEGO的北向能力，每一個所述功能自治包面向接口開發且每一個功能自治包之間相互獨立，從而解決了傳統OSGI框架的全量引用問題和細分市場的定制化服務組裝、覆蓋問題，嚴格的分層面向接口架構，同時又能夠帶來軟件質量、穩定性的保障。

技術領域

本發明屬于軟件設計技術領域，尤其涉及一種平臺插件化軟件研發構架及其設計方法、系統。

背景技術

以面向Java的動態模型系統OSGI為代表的插件化開發架構，此架構歷經十多年的打磨，已經形成了業內的標準化可插拔框架。OSGI的思想為組件Bundle的自治，但存在組件Bundle之間的依賴，如某Impl包需要通過導入導出包的形式引用另外一個Impl包的接口，但是服務的調用通過組件Bundle之間注冊的接口服務進行，并不直接方法級別調用，從而明確了組件Bundle的邊界。但是由此帶來一個問題，無需的組件Bundle可以服務沒有加入，但是依賴必須加入，也就是說，組件Bundle之間如果存在導入導出的情況，依賴就必須是全量的，由此軟件的安裝包就比所需的大的多。而且OSGI包的研發方式與普通MAVEN研發存在多引用源無關的問題，無法確定以哪個為標準，必須另外借助其他插件，也就給軟件代碼的遷移帶來了負擔。任何架構設計均有利弊，OSGI為了其他方面的便捷，因此就舍棄了此依賴的問題。

一個產品的誕生，必然經歷MVP的階段，也就是說，每個產品都會存在一些核心的軟件功能。這些功能在整個產品的迭代過程中都是重中之重，也是期望能夠穩定運行的。因此，這些功能的包能夠獨立為一個最小化的產品部署，也不期望對此部分內容進行大量的改動，希望能夠穩定下來。可是，如果有某個細分市場出現了定制化或者衍生產品，再想利用此MVP就變得極為困難，原因有二點。一，細分市場必然存在需求不一致，變動如何修改，一旦修改就無法共用MVP。二，一旦沒有共用同一庫的最小可行性產品MVP，必然會導致MVP的缺陷不能及時分析、及時同步到各個細分市場中。那么，產品的質量就會大打折扣，MVP期望的效果也就蕩然無存。

發明內容

針對現有技術中的缺陷，本發明提供了一種既能消除OSGI全量引用，又能解決MVP復用問題的平臺插件化軟件研發構架。

本發明所提供的技術方案是：一種平臺插件化軟件研發構架，包括獨立平臺數據庫LEGO、軟件研發包和若干個功能自治包；

其中，所述獨立平臺數據庫LEGO包含有表征其功能的標識，所述軟件研發包表征所述獨立平臺數據庫LEGO的北向能力，每一個所述功能自治包面向接口開發且每一個功能自治包之間相互獨立。

作為一種改進的方案，所述軟件研發包內包含有在研發設計過程中所必需的各類BEAN、INTERFACE內容，所述軟件研發包遵循最小化依賴原則，每一個所述功能自治包內提供實現。

作為一種改進的方案，若干個所述功能自治包中的其中幾個功能自治包結合所述軟件研發包打包生成新的服務。

作為一種改進的方案，當所述功能自治包的接口處于無用狀態時，對所述接口進行重寫。

本發明的另一目的在于提供一種基于平臺插件化軟件研發構架的平臺插件化軟件研發構架的設計方法，所述方法包括下述步驟：

定義一個獨立平臺數據庫LEGO，其中，所述獨立平臺數據庫LEGO包含有表征其功能的標識；

定義一基于研發平臺的軟件開發包，其中，所述軟件研發包表征所述獨立平臺數據庫LEGO的北向能力；

定義若干個基于所述研發平臺的功能自治包，其中，每一個所述功能自治包面向接口開發且每一個功能自治包之間相互獨立。