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

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

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

本文只着重於客戶端頁面層，弄清楚頁面層後服務端的工程結構應不難想象。爲便於書寫，咱們設計了一個場景：呼叫中心繫統裏跑檔案和呼叫兩個業務。

界面層

咱們來看看界面層內部有哪些源程序工程，以及它們之間的依賴關係，以下：

 

上面的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獲取到系統會話，又能經過依賴各業務工程加載對應的頁面。

數據集成

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

打開另外一個頁面就須要知道該新頁面的一些信息，但因爲咱們不容許兩個業務工程存在依賴關係，所以遇此需求時咱們可經過ui-core進行中轉。例如，假設打開一個頁面須要獲取到其class才行，而且咱們又不但願經過反射來獲取，此時咱們可經過接口和依賴注入來完成，以下：

• 在cc-ui-core工程裏建一個接口：

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

• 在cc-ui工程裏實現該接口。因爲cc-ui依賴全部的業務工程，所以可輕易獲取到所需信息。

• ic-ui工程因爲依賴ui-core工程，所以可經過依賴注入獲得該接口，並進而調用該接口的方法來獲取到所需信息。

總結

咱們提出的工程模型可用這樣一句話來歸納，即業務在系統裏跑。系統一方面負責加載業務頁面，另外一方面又經過傳遞系統會話輔助業務頁面的開發。