需求分析能力之範例：引入領域模型的前前後後

曾經遇到過一個系統需求，需求分析人員在聽到客戶說要增加"修改員工密碼"功能後，就原封不動的把這個功能寫在了文檔中。如果把這個需求交給實現人員，很多實現人員，會在"員工"（Employee）這個類中加一個屬性"password"。如果僅用名詞法，來驗證需求，完全符合："員工"，是一個比較重要的概念。"什麼的什麼，可以提取為屬性"，因此"員工的密碼"可以提煉為"員工"類的password屬性。

實現人員噓了口氣："萬事OK。"

真的OK嗎。

需求情境：員工和使用者的分離。

如果把密碼放在了員工中，基於CRUD的做法，我們通常會把對員工的修改放到了一個介面上。也就是說，管理員增加一個人員，系統預設設定對應人員的密碼。

這個時候，IT部門提出異議了，增加員工，是人力資源部門的事情，而是否給員工開放帳號，是資訊中心的事情，不是所有的員工都開放帳號的，HR部門無權擅自開放帳號。

"帳號。"，"是啊，"IT部門的人說，"使用者帳號啊"。

得，我們丟了一個重要的概念 －－使用者。

同樣的道理，員工辦理離職的時候，也是要先去資訊中心銷戶，然後再去HR部門辦理離職，因此，我們把Password放到員工中，是不合適的。員工需要和使用者分開。

需求情境：員工和客戶、供應商、夥伴的合并：

客戶提出新的需求：原先我們建立的都是員工和密碼，現在，我們要打通企業的供應鏈，給我們的供應商和客戶包括夥伴，有條件的開放系統的功能。因此，他們也要有帳號和登入密碼。

是分開設定代理，還是把他們合并成一個抽象類別。在不考慮系統效能的前提下，我們可以暫時套用《分析模式》的做法，抽象出Person （或Party）領域對象來。

需求情境：分別的帳號登入

客戶說："我希望員工在登入後，只選擇他想使用的崗位角色。"什麼意思。

"比方說張X，在集團公司內是出納，而在集團的某個下屬公司，是會計，他上午在集團上班，下午，在下屬公司上班。因此，登入的時候，需要選擇角色。"

客戶是不會太輕易的就區分出員工和使用者的區別的，在描述的時候，就會混淆著使用員工和使用者這兩個概念。另外，崗位和角色，也是非常類似的兩個概念。

在沒有統一的獨立的登入伺服器的情況下，你感覺，這種方式實現起來有問題（想想，都會有什麼問題。），於是說服客戶："給你建兩個帳號行嗎。"，使用者也沒有細考慮，居然同意了。因此，這時的一個Person，就對應了兩個帳號，密碼呢。自然不能放到Person中了。

我們再想像一下這時的登入過程，簡單的互動步驟如下。

actor使用帳號和密碼登入，

系統驗證帳號和密碼有效，顯示允許的功能操作。

需求情境：選擇性啟用

如果客戶堅持只能一個人只能用一個使用者帳號登入，會是什麼樣子。

使用使用者帳號 和password 登入，系統需要列出其所有的角色，角色按所屬公司列出，

actor啟用某公司下的某種角色。（關於角色的動態啟用，可以參考RBAC模型，這裡不再多講。）

要考慮的問題就產生了（用例中的擴充流）：

actor已經在其他的地方登入了系統（啟用了其它角色了）怎麼辦。

我們現有的領域模型是，角色是跟公司（法人）相關的，如果客戶又提出，角色和部門相關，哪該怎麼辦。

需求情境：限界上下文

我和BSP的主要負責人建華，曾經就人員和使用者，以及崗位和角色的類似，進行了大量的討論。得出來的結論是，這是從不同的角度在看待同一事物，在企業資源模型中，HR是重要的企業資源，而在許可權模型中，人力是作為受限單元的。因此，他們應該分屬於兩個不同的限界上下文，而限界上下文，也是領域模型的一個重要的組成部分。

題外話：

作為LoushangBSP產品的參與者，我曾經為這些需求問題（比我舉出來得要多的多）困擾過許久，還好，現在，BSP中的組織機構和許可權模型已經相對豐富，足以應對這些需求情境了，現在，我可以把一些簡單的需求，共用給大家。