區分系統與業務的工程劃分方法

標籤：

區分系統與業務的工程劃分方法

如何劃分一個系統的來源程式工程？這裡提出一個基於系統和業務的工程劃分模型，這個模型的特點是要區分出哪些是系統工程、哪些是業務工程。

本文只著重於用戶端頁面層，弄清楚頁面層後服務端的工程結構應不難想象。為便於書寫，我們設計了一個情境：話務中心系統裡跑檔案和呼叫兩個業務。

介面層

我們來看看介面層內部有哪些來源程式工程，以及它們之間的依賴關係，如下：

 

上面的cc-ui-core和cc-ui是兩個系統工程，file-ui是關於檔案的業務工程，ic-ui是關於呼叫的業務工程。這些工程之間的依賴關係中箭頭方向所示。

該工程模型具有如下特點：

• 一個系統有系統和業務兩類工程。
• 每個系統分ui-core和ui兩個系統工程，其中，ui-core工程被業務工程所依賴，而ui工程依賴其它各業務工程。
• 業務工程之間不發生依賴關係。一個業務頁面不依賴於另一個業務的頁面，但同類業務的頁面之間可（單向）依賴。
• 各工程之間不存在雙向或循環相依性。

下面我們看看該模型解決了哪個問題。

系統會話

使用者登入後系統就確定了目前使用者的工作環境資訊，我們稱之為系統會話。例如使用者登入進某話務中心後，系統會話就儲存了該使用者的話務中心ID。當使用者為客戶辦理業務時，系統會話就充當了辦理業務的工作環境。仍以話務中心為例，業務記錄裡的話務中心ID欄位應無必要也不允許在業務介面裡輸入。

因此，我們把系統會話放在cc-ui-core工程裡，並讓各業務工程通過依賴能訪問到系統會話對象。

頁面整合

至少有兩種整合的情景。

• 菜單及工具條。例如，點擊菜單後開啟某個業務頁面。這要求菜單依賴業務頁面。
• 跨業務頁面。例如，話務中心系統裡有一個顯示當天建檔數和辦理呼叫人次的頁面。此時我們應獨立開發這個頁面。

我們把這些整合頁面放在cc-ui工程裡開發，該工程既能通過依賴cc-ui-core擷取到系統會話，又能通過依賴各業務工程載入對應的頁面。

Data Integration

上面說到，兩個業務工程之間不依賴。但頁面需求靈活多變，例如，我們需要在呼叫頁面裡開啟客戶檔案，如何開啟呢？

開啟另一個頁面就需要知道該新頁面的一些資訊，但由於我們不允許兩個業務工程存在依賴關係，因此遇此需求時我們可通過ui-core進行中轉。例如，假設開啟一個頁面需要擷取到其class才行，並且我們又不希望通過反射來擷取，此時我們可通過介面和依賴注入來完成，如下：

• 在cc-ui-core工程裡建一個介面：

public interface Provider {    Class<?> filePageClass();}

• 在cc-ui工程裡實現該介面。由於cc-ui依賴所有的業務工程，因此可輕易擷取到所需資訊。

• ic-ui工程由於依賴ui-core工程，因此可通過依賴注入得到該介面，並進而調用該介面的方法來擷取到所需資訊。

總結

我們提出的工程模型可用這樣一句話來概括，即業務在系統裡跑。系統一方面負責載入業務頁面，另一方面又通過傳遞系統會話輔助業務頁面的開發。

區分系統與業務的工程劃分方法