從2013年計算機專業畢業，剛好參與一個資訊系統的構建過程。到現在，該系統進入維護週期，已經有五年了。既參與了前期的開發，也負責起後期的維護，前期摸石頭過河留下的坑，都在維護中被艱難的填了。維護不易。

在維護的過程中，發現很多需要優化、再設計的地方，但奈何系統已經成型，並且穩定執行，再設計的代價非常的高，基本是不現實的。於是，我開始想，如果重新設計，要該怎麼去做。然後思來想去，並沒有一個標準答案。（可能我書還是看的少了）

下面記錄幾個困惑的地方。

1.領域實體模型的屬性的增加和刪除如何處理

1.1 增加一項屬性

    比如，在員工薪資管理系統，員工是個領域實體模型。員工模型有個屬性是學歷（也可用其它使用者可自定義的屬性舉例），在錄入員工資訊時，需要選擇該員工的學歷。因為學歷是比較常見的：大專、本科、碩士、博士，系統開發的早期學歷被硬編碼為這麼幾個也沒有什麼問題。但後期的時候突然要求增加：高中/中專、博士後，那怎麼辦呢？

1. 修改硬編碼的程式碼，繼續增加學歷，硬編碼。
2. 把學歷單獨做個數據庫表，然後交由使用者去增加刪除
3. 把學歷儲存在配置檔案中

1. 這個對於學歷這種不常變化的，可以這樣做。但如果較頻繁一點，令人頭疼。

2. 這個感覺太笨重，學歷只是一個並不核心的業務資訊，單獨做表，就兩個欄位做個表，然後再做增刪，價效比不高。

3. 沒有嘗試過。但有個問題就是配置檔案的某項的更新和刪除操作會引起下面1.2 和 1.3 的問題。

1.2 刪除一項屬性

其實，相對於 增加 這種可以硬編碼的小問題，刪除才是令我困惑的。

假設，學歷內容是儲存在資料庫表中，1對應大專、2對應本科、3對應碩士、4對應博士。職工張三的學歷是<1，大專>，突然有一天，系統調整，需要去除“大專”學歷（我們舉例而已），那麼系統如何做更改？

1. 真刪除學歷表中該項記錄，那麼張三的學歷資訊就徹底的丟了。這如果不是學歷，是重要的業務資訊，豈不慘了。
2. 假刪除，錄入新員工資訊時，大專選項確實沒有了。但我們查詢歷史資料時，張三的學歷一欄該顯示什麼呢？只顯示個 1 麼。學歷資訊豈不是也丟了。

1.3 更新一項屬性

更新和刪除，問題是一樣的。

將<1，大專>記錄更新為<1，博士後>，這肯定亂套了。按道理，是不能更新為其它不同含義的。

2.領域實體模型的型別屬性

同樣的，員工有個屬性是英語等級，CET4和CET6，擅長語言有英語、德語、俄語，這些屬性值到底是該怎麼儲存。肯定不能硬編碼，寫死在程式碼裡。但是單獨為英語等級、擅長語言建個一個又一個表，也太費事了。

3.管理資訊的角色與許可權

在系統構建早期，我們都認為 角色是許可權的集合，在系統體現出來就是，每個使用者可勾選多個角色，每個角色可勾選多個許可權，每個許可權控制一些選單和按鈕。

然後，當系統中出現“流程控制類”的功能（如公文流轉）時，流程控制中也出現了個“角色”，而這個“角色”卻和原來的角色不同。新的角色，和系統許可權並不掛鉤，而是在小小的流程控制模組中發揮著“身份”的作用。

比如專案組長的身份，專案總監的身份，各代表著一定的收發公文、轉派公文、簽收公文、稽核簽字的功能，顯然與系統中的“系統管理員”、“部門管理員”等角色含義大不相同。但在我們的系統中卻混為一談，把單個模組中的“角色”也當作系統“角色”統一放在了一個數據表中，一起進行維護，結果就是混亂！

如果能重新設計，我覺得“流程控制”類的功能裡面的“身份”應單獨抽象建表，作為該子模組的“角色”表，而不要和系統級別的“角色”概念混用。這樣二者都可賦予給使用者，系統角色不代表流程控制裡的身份。

4.不同Web系統之間的資料同步

這才是最頭疼的大問題。

如果在不同的Web系統之間同步資料，我只瞭解到有 WebService，但WebService非常依賴對方，對方服務一旦宕機，資料傳輸就斷了。也不能實時的傳輸大量資料。

就先記錄這些吧。