軟體模組和領域概念

標籤：軟體   模組化   

技術上我們經常強調模組化、組件化，但是能真正實現軟體模組化，需要通過對業務領域有一定程度的理解才能達到。

我們可能有專業培訓組件和模組技術的課程（OSGi等），但這類課程並不會告訴我們所在的領域上具體情況應該如何劃分模組，大概辨別和劃分模組的能力是理所當然。但事實上並非如此。

用一個例子說明：假如一個網站需要添加一個廣告功能。大概有以下可能性：

• 如果該網站本來是沒有模組化的，直接就往代碼裡做修改。而後果會是代碼越來越龐大
• 如果該網站已經劃分了不同的模組，我們會看看新的功能是否屬於哪個曾經定義過的模組，然後新的代碼會在這個模組裡添加
• 如果新功能不屬於任何曾經定義過的模組，我們會建立一個新的模組。

最後兩點的關鍵在［屬於］如何界定。

新的廣告功能［屬於］內容管理（CMS）的一部分嗎？畢竟廣告也會有內容的特性（有文字，圖片，超連結等等）。

廣告功能也可以自成一個模組，因為廣告的點擊率直接影響網站收益，跟網站內容的點擊性質不一樣，處理的結果也可能不一樣。

另外有可能廣告功能是市場部管轄的範圍，廣告的效果經過分析後可能會到業務部和財務部做核算。從業務流我們也可以認為這個廣告功能屬於市場部的一個系統功能。

在Eric Evans的Domain Driven Design提倡領域設計的重要性，當中Bounded Context提到模型邊界問題。而Sam Newman在Building Microservices書中也提到微服務最好也依據Bounded Context來劃分。

通常我會依據以下關係來做模組劃分：

• 領域對象的擁有者和使用者
• 根據企業的常態範圍（部門）分析
• 是否存在一種虛擬抽象的關係，把兩個看起來沒有關係的領域關聯起來，而這個虛擬抽象的東西可能就是一種共用的高維度模組

另外有兩個重要的技術概念也需要參與分析：低耦合性，高一致性

• 低耦合 ＝ 改變一個模組的代碼，不導致需要修改依賴這模組的其他模組的代碼
• 高一致性 ＝ 同一個領域的對象，儘可能放在一起並一起發布

還有一個簡單的檢查，就是通過換位思考，站在一個領域的角度上，判斷這個領域詞彙應該在什麼模組出現、和不應該在什麼模組出現。

軟體模組和領域概念