DDD案例（1）:從需求分析到領域分析

20.3.1EAS案例背景

企業應用套件[1]是一款根據軟件集團應用信息化的要求開發的企業級應用軟件。該軟件集團為各行各業提供軟件交付服務，以在岸、近岸、離岸等多種模式交付軟件。EAS系統提供了大量簡單、快捷的操作界面，使得集團相關部門能夠更快捷、更方便、更高效地處理日常事務工作，並為管理者提供決策參考、流程簡化，建立集團與各部門、員工之間交流的通道，有效地提高工作效率，實現整個集團的信息化管理。

EAS系統為企業搭建了一個數據共享與業務協同平台，實現了人力資源、客戶資源和項目資源的整合。系統包括人力資源管理、客戶關係管理和項目過程管理等主要模塊。系統用戶為集團的所有員工，但角色的不同，決定了他們關注點之間的區別。

20.3.2EAS的全局分析

在全局分析階段，需要針對目標系統進行價值需求分析。

1．價值需求分析

根據參考過程模型的描述，一種有效方法是通過商業模式畫布來幫我們確定目標系統的客戶、願景和範圍。EAS是一款面向B端的產品，它的客戶實際上都是軟件集團的員工。員工的角色不同，所屬部門不同，職責也不相同，因而對其做客戶細分非常有必要。實際上，我們在為EAS進行價值需求分析之前，重點調研了人力資源部、市場部與項目管理部的相關人員。作為支持者（提供部門的業務知識）與受益者（使用EAS的最終用戶），他們各自提出了切合自身需要的業務功能，包括：

q市場部對客戶和需求的管理，對合同的跟蹤；

q項目管理部對項目和項目人員的管理，對項目進度的跟蹤；

q人力資源部負責招聘人才，管理員工的日常工作包括工作日誌、考勤等。

在對EAS的客戶進行細分並確定各自的價值主張時，團隊發現遺漏了最重要的利益相關者：集團管理層。作為集團業務的決策者，他們對業務目標的認識有利於更加準確地確定系統願景。

作為一家提供軟件交付服務的集團公司，核心生產力是從事軟件開發的人力資源。各個業務部門的主要工作都是圍繞着人力資源的供需進行的。決策者的痛點就是無法快速直觀地了解公司人力資源的供需情況。例如，客戶需要集團提供20名各個層次的Java開發人員，市場部門在確定是否簽訂該合同之前，需要通過EAS查詢集團的人力資源庫，了解現有的人力資源是否匹配客戶需求。如果匹配，還需要各個參與部門審核人力成本，決定合同標的。如果集團當前的人力資源無法滿足客戶需求，就需要人力資源部提早啟動招聘流程，或從人才儲備庫中尋找滿足需求的候選人。通過EAS，管理人員還能夠及時了解開發人員的閑置率，跟蹤項目的進展情況，明確開發人員在項目中承擔的職責和任務完成質量。

獲得商業模式畫布的渠道通路比較簡單。這是因為EAS與其他創新產品不同，並不需要尋找各種渠道通路對產品進行宣傳，只需利用行政力量要求相關部門使用即可。由此推導出來的客戶關係，實際上就是對參與EAS系統的各種角色做進一步梳理，了解這些角色在什麼時候會使用EAS，又該怎樣使用EAS。

EAS是集團的內部系統，不牽涉具體的營收業務，因此它的收益來源更多地體現在對成本的控制和削減上，同時也包含該如何為集團的軟件交付業務提供更好的服務與支持。雖然EAS的收益來源並不明顯，但對它的思考有利於驅動我們對核心資源和關鍵業務的發掘。

為了保證EAS的順利交付，需要哪些核心資源？交付的EAS能夠提供哪些關鍵業務？在確定了EAS的客戶、價值主張、收益來源等內容後，參與到商業模式畫布頭腦風暴的人員能夠輕易回答這些問題。由於EAS主要解決人力資源問題，它需要的重要合作也應該與人力資源的招聘、培訓有關。最後，EAS是企業內部系統，在考慮實現該系統之前，了解開發該系統需要的成本結構也就顯得理所應當。由此，就可以獲得圖20-4所示的商業模式畫布。

[1] 本例的詳細需求、設計和代碼請在GitHub中搜索“agiledon/eas-ddd”獲取。

圖20-4EAS的商業模式畫布

雖然EAS並非一個創新產品，但在全局分析階段通過它探索價值需求，會更容易引導客戶描繪出心中的設想，並通過這種可視化的形式將其真實地傳遞出來，形成對問題空間一致理解的，就價值需求達成共識。

一旦確定了商業模式畫布的內容，就可以根據商業模式畫布各個板塊與價值需求之間的關係，獲得EAS的價值需求，作為全局分析規格說明書的一部分。組成EAS全局分析規格說明書的價值需求如下所示。

1 利益相關者

q 集團決策者

q 子公司

q 人力資源部

q 市場部

q 項目管理部

q 項目管理辦公室

q 財務

q 員工

q 服務中心

2 系統願景

　　避免信息孤島，實現人力資源的可控，從而達到人力資源的供需平衡。

3 系統範圍

3.1 當前狀態

q 創建了由項目經理、業務分析師、開發人員和測試人員構成的特性團隊

q 集團項目管理部負責項目的流程管理

q 集團已有OA系統作為部門之間的流程協作與消息通知

q 集團已制訂了人才招聘管理辦法、項目過程管理辦法

q 軟件學院和招聘網站的簡歷作為集團的人才儲備庫

q 員工培訓已有合作的培訓公司

q 市場部提供客戶和潛在客戶名單

q 由集團下達行政命令在集團內部相關職能部門推廣EAS系統

3.2 未來狀態

q EAS系統在×年×月×日通過用戶驗收

q EAS系統在×年×月×日上線運行

q 由EAS系統負責客戶關係管理、項目管理、人力資源管理

q 通過客戶滿意度評估EAS系統的價值

3.3 目標列表

q 通過可視化方式體現人力資源的供需狀況

q 管理集團與客戶和潛在客戶之間的關係，管理市場需求，對合同進行跟蹤

q 管理項目和項目人員，跟蹤項目進度

q 實時調整用人需求，制訂招聘和培訓計劃

q 管理員工考勤、工作日誌等日常工作

2．業務需求分析

在完成價值需求分析後，就可以在價值需求的引導與約束下開始業務需求分析。

業務需求分析起始於業務流程，能讓目標系統的業務功能“動”起來，執行一系列的活動來滿足參與角色的業務價值。為了快速把握EAS的需求全景，可以抓住體現業務願景核心價值的主流程。既然EAS以“人力資源的供需平衡”為關注核心，那麼所有參與角色需要執行的主要業務功能都與該核心價值有關。在價值需求的指引下，可以結合供需平衡將所有參與角色抽象為需求方與供應方，然後站在供需雙方的角度思考各個參與角色之間的協作方式與協作過程，如圖20-5所示.

圖20-5EAS的核心業務流程

圖20-5清晰地體現了需求與供應之間的關係，展現了核心業務流程的關鍵環節。注意，該協作示意圖並非項目開始之前的當前狀態，而是期望解決供需平衡問題的未來狀態。這種協作關係也體現了打破部門之間信息壁壘的系統願景。根據這一協作示意圖，我們可以以泳道圖形式的業務流程圖表達整個系統的核心流程，如圖20-6所示。

這個核心流程體現了業務流程的總體運行過程，屬於更為宏觀的業務流程表達。許多更為細緻的協作細節並沒有清晰地表現出來，項目管理流程和招聘流程更是作為子流程被“封裝”起來了。為了更為詳盡地探索問題空間，這些業務流程也需要進一步得到呈現。從目標系統為參與角色提供服務的角度，我們通過服務藍圖結合業務流程圖呈現了EAS的以下業務流程。[1]

q面向市場人員：客戶合作的業務流程。

q面向項目管理人員：項目管理流程。

q面向培訓專員：培訓流程（培訓需求是後續提出的需求變更）。

[1] 限於篇幅，本章只提供幾個典型的業務流程。

圖20-6　核心流程的泳道圖

由於EAS的所有用戶都是組織內員工，如果使用服務藍圖繪製業務流程，客戶角色就是向目標系統發起服務請求的用戶，如簽訂合同業務流程中的市場人員、項目管理流程的項目管理人員和招聘流程的招聘專員。

（1）客戶合作

當市場人員向目標系統發起創建市場需求的服務請求時，就形成了從市場需求到合同簽訂並形成需求訂單的客戶合作業務流程，它的服務藍圖如圖20-7所示。

由於業務規則要求具有獨立法人資格的子公司作為市場需求的承擔者，因此子公司會成為合同中的乙方。市場人員作為服務藍圖中的客戶，並不會參與合同的簽訂，只是關心子公司的現有資源能否滿足市場需求。在簽訂了合同之後，市場人員可以通過合同信息創建需求訂單，並跟蹤需求訂單，以保持與客戶合作的良好關係。子公司作為前台員工需要與市場人員交互，但是市場人員卻看不見財務的參與，因為財務核算行為發生在作為前台員工的子公司與財務之間，因此財務屬於服務藍圖的後台員工。至於內部支持者，要麼是EAS自身，要麼就是EAS範圍之外的外部系統。

根據客戶合作流程的服務藍圖，整個流程由4個業務場景構成：市場需求管理、簡歷管理、合同管理和需求訂單管理。根據業務服務的判斷標準，對業務場景的活動進行判斷，可以繪製出每個業務場景的業務服務圖。

市場需求管理的業務服務圖如圖20-8所示。

對“查詢市場需求”業務服務而言，它雖然沒有包含在服務藍圖，但在子公司對市場需求進行評估時，如果不提供這一功能，就無法獲得指定的市場需求完成評估。二者提供的服務價值又是完全獨立的，有必要為其單獨定義一個業務服務。

簡歷管理的業務服務圖如圖20-9所示。

客戶合作的業務流程說明是由系統生成員工簡歷，但實際上，這需要子公司的操作人員與系統進行一次交互，目的是導出員工簡歷，故而識別出該業務服務以滿足功能需求。

合同管理的業務服務圖如圖20-10所示。

合同的簽訂在線下進行，EAS系統只負責維護合同信息，並將合同掃描版上傳到系統中歸檔，以便市場人員查詢合同信息，因此，業務流程中的簽訂合同活動並未出現在合同管理的業務服務圖中。市場人員創建合同的目的其實是歸檔，以便相關人員（主要是市場人員）查詢，故而“歸檔合同”體現了該業務服務的服務價值。

需求訂單管理的業務服務圖如圖20-11所示。

在梳理客戶合作流程的業務服務時，我發現幾個領域概念的定義並不清晰：合同、市場需求客戶需求和需求訂單之間的關係是什麼？存在什麼樣的區別？

當我們發現有多個混亂的領域概念需要澄清時，就要建立統一語言，就這些領域概念達成一致共識。

通過與市場人員的交流，我發現市場部對這些概念的認識也是模糊不清的，甚至在很多場景中交替使用這些概念。在交談過程中，他們有時還提到“市場需求訂單”這個概念。例如在描寫市場需求時，他們會提到“錄入市場需求”，但同時又會提到“跟蹤市場需求訂單”和“查詢市場需求訂單”。在討論“客戶需求”時，他們提到了需要為客戶需求指定“承擔者”，在討論“市場需求”時卻並未提及這一功能。這似乎是“客戶需求”與“市場需求”之間的區別。對於“合同”的理解，他們一致認為這是一個法律概念，等同於作為乙方集團或子公司和作為甲方的客戶簽訂的合作協議，並以合同要件的形式存在。

鑒於這些概念存在諸多歧義，我們和市場人員一起梳理統一語言，一致認為需要引入“訂單”（order）的概念。訂單不是需求（無論是客戶需求還是市場需求）。它借鑒了電商系統中的訂單概念，用於描述市場部與客戶達成的合作意向。每個合作意向可以包含多個客戶需求，相當於訂單中的訂單項。例如，同一個客戶可能提出3條客戶需求：

（1）需要5名高級Java程序員、10名中級程序員；

（2）需要8名初級.NET程序員；

（3）需要開發一個OA系統。

這3條客戶需求組成了一個訂單。一個訂單到底包含哪幾個客戶需求，取決於市場部與客戶洽談合作的業務背景。

引入訂單概念後，市場需求與客戶需求的區別也就一目了然了。市場需求是市場部售前人員了解到的需求，並未經過評估；公司也不知道能否滿足需求，以及該需求是否值得去做。這也是市場需求無須指定“需求承擔者”的原因。市場需求在經過各子公司的評估以及財務人員的審核後，就可以得到細化，並在與客戶充分溝通後，形成訂單。每一條市場需求通過評估，轉換為訂單中的客戶需求。

我們仍然保留了“合同”的概念。“合同”領域概念與真實世界的“合同”法律概念相對應。它與訂單存在相關性，但本質上並不相同。例如，一個訂單中的每個客戶需求可以由不同的子公司來承擔，但合同卻規定只能有一個甲方和一個乙方。訂單沒有合同需要的那些法律條款。未簽訂的合同內容確實有很大部分來自訂單的內容，但也只是商務合作內容的一部分而已。在確定了訂單後，市場部人員可以跟蹤訂單的狀態，並且在訂單狀態發生變更時，修改對應的合同狀態，但合同的狀態與訂單的狀態並不一致。

在全局分析階段執行業務需求工作流時，一定要使用統一語言。我們通過業務服務圖將業務服務可視化後，對於每一個可能產生歧義的領域概念，一定要大聲說出來，及時消除分歧與誤解，形成團隊內部的統一語言。

（2）項目管理

當項目管理人員（通常為指定該項目的項目經理）開始發起項目立項的服務請求時，就形成了從立項到結項一個完整的項目管理流程，其服務藍圖展現如圖20-12所示。

項目管理流程由項目管理人員提交立項申請開始，從管理角度經歷了一個項目的完整生命周期。項目管理人員扮演了服務藍圖的客戶角色，整個流程的各個階段都是為項目管理人員服務的。諸如子公司、項目管理部、項目成員和服務中心等只參與項目管理流程，提供交互或支撐行為。

項目管理流程為項目管理人員提供了業務價值。如果要體現目標系統為項目成員提供的業務價值，就需要將項目成員當作服務藍圖的客戶，思考它的客戶旅程，例如處理迭代問題的流程。可以單獨為這個流程繪製服務藍圖。由於視角不同，參與角色的身份也會發生變化。

項目管理流程根據業務目標的不同，分成了4個業務場景：項目管理、項目成員管理、項目計劃管理和問題管理。此外，服務中心對硬件資源的分配屬於項目管理場景的支持場景，也需要考慮。

在項目管理流程中，同為項目管理目標的業務場景被拆分到首尾兩個階段。在確定項目管理場景的業務服務圖時，需要將這兩個階段的業務服務統一，形成圖20-13所示的項目管理業務服務圖。

服務中心對硬件資源的分配支持了項目立項活動，為整個項目的項目組分配了資源，作為一種支撐活動放在一個單獨的業務場景中。其業務服務圖如圖20-14所示。

分析項目成員管理場景的活動。在添加或移除團隊成員時，需要通過OA系統發送通知。通知的發送不在目標系統範圍內，也不是由某個參與者發起，而是在添加或移除了團隊成員之後進行，屬於業務服務的執行步驟，不需要列入圖20-15所示的業務服務圖。

項目計劃管理也分成了兩個階段，合併為一個業務服務圖，如圖20-16所示。

問題管理業務場景的業務服務圖如圖20-17所示。

“問題”（issue）概念的獲得並非一蹴而就。一開始，我傾向於使用任務（task）來表達這一概念，然而，在需求管理體系中，任務與用戶故事（user story）、史詩故事（epic）、缺陷（defect）屬於同一等級的概念，我需要尋找到一個抽象概念來同時涵蓋這幾個概念，由此就得到了“問題”概念。在Jira和GitHub的需求管理工具中，都使用了這一領域概念。

項目管理者在創建問題時，會指定問題的基本屬性，如問題的標題、描述、問題類型等。那麼，問題所屬的迭代、承擔人（owner）、報告人（reporter）是否也屬於問題的屬性呢？在確定問題管理業務場景的業務服務圖時，我確實困惑不已。例如“分配問題給迭代”與“分配問題給項目成員”都可以認為是在編輯問題的屬性。既然業務服務為角色提供了服務價值，很明顯，無論是將一個創建好的問題分配給迭代，還是將其分配給項目成員使其成為問題的承擔人，都具有項目管理價值，是由項目管理者向目標系統發起的一次獨立而完整的功能交互，應該分別識別為兩個業務服務。

在確定項目管理的業務服務時，統一語言再一次發揮了價值。最初在確定項目管理的業務流程時，項目管理者要查看問題的完成情況以了解迭代進度，故而將該流程中的一個活動命名為“查看問題完成情況”。在識別業務服務時，我認為該名稱沒有清晰地體現該業務服務的服務價值，經過與業務分析人員溝通，認為該業務服務需要清晰地表達問題在迭代周期內的過程，準確的術語是“進度”（progress），將其命名為“跟蹤問題進度”（trackingissue progress）更加符合該領域的統一語言。

（3）培訓

培訓的目的是提高員工的技能水平，需要根據員工的職業規劃與企業發展制訂培訓計劃，開展培訓。培訓的整個管理由人力資源部的培訓專員負責。培訓流程除了牽涉到培訓專員，還牽涉到部門協調者、員工主管和員工本人。系統將分配給員工的培訓機會稱為票（ticket），這實際上是領域概念的一種隱喻。培訓專員發起培訓的過程，實際上就是分配票的過程，整個流程如圖20-18所示。

培訓專員在分配票之前，會設定過濾器。過濾器主要用於過濾員工名單，獲得一個與該培訓相匹配的提名候選名單（candidate）。培訓專員將票分配給部門協調者，部門協調者再將票分配給屬於提名候選名單中的部門員工。員工在收到培訓郵件後，可以選擇“確認”或“拒絕”，若員工拒絕，票會退回給部門協調者，由部門協調者進行再分配，最終會形成一個提名名單（nomination）。

培訓期間，每個參與培訓的員工都需要通過培訓專員出示的二維碼簽到，包括培訓開始簽到和培訓結束簽到。培訓結束後，培訓專員可以獲得出勤名單。比較出勤與提名名單，可以獲得缺席名單。培訓專員確認了缺席名單後，系統會根據黑名單規則將缺席人員加入黑名單。員工若被列入黑名單中，將來就不會再出現在提名候選名單中，除非又被移出了黑名單。培訓流程如圖20-19所示。

圖20-19　培訓的服務藍圖

培訓專員在確定培訓計劃並分配票時，還可以事先設置有效日期，用於判斷票的有效期限。從發起培訓開始，到培訓結束，一共有4個重要的截止時間（deadline）：

q提名截止時間；

q缺席截止時間；

q培訓開始前；

q培訓結束前。

在不同的截止時間，員工取消票的流程都不一樣，票的處理規則也不相同，如圖20-20所示。

在提名截止時間之前，獲提名的員工可以取消票。取消後，系統會分別發送郵件給部門協調者與員工主管，只要任意一人批准了該取消請求，就認為取消成功，該票又會恢復到可用狀態。在缺席截止時間之前，員工可以取消票。取消後，系統會發送郵件通知部門協調者和員工主管，但無須他們審批，而是直接由培訓專員負責處理該票。處理票時，會先檢查分配該票時設置的活動（action）策略，要麼由系統自動處理，要麼由培訓專員處理該票。處理票有3種活動策略：

q將票分享給別的協調者；

q將票分配給員工；

q讓票作廢。

在培訓開始前，不允許員工再顯式地取消票。如果員工在收到票後一直未確認，系統會檢查分配該票時設置的策略，要麼由系統自動處理，要麼由培訓專員處理該票，處理票的策略與前相同。一旦培訓開始後，就不再允許員工取消票，如果有事未能出席，應提交請假申請。

部門協調者在將票分配給員工後，也可以取消已經分配出去的票。不同截止日期的取消流程不同，如圖20-21所示。

部門協調者取消票的流程與員工取消票的流程比較相似，不同之處在於取消票時無須審批，直接就可處理。在提名截止時間之間，處理票的活動策略有3種：

q備選名單先到先得；

q備選名單按優先級；

q手動從備選名單中選擇。

這裡的提名備選名單（backup）就是從之前設置的過濾器生成的提名候選名單中剔除掉已經被提名的員工列表後的名單。

培訓專員也可以取消票，其流程如圖20-22所示。

該執行流程與部門協調者取消票的流程幾乎完全相同，這裡不再贅述。

在分析培訓流程時，我分別運用了服務藍圖和業務流程圖展現了分配票、培訓和取消票的業務流程，並根據不同階段的業務目標確定了業務場景。

票的分配業務服務圖如圖20-23所示。

在明確票的分配業務場景下的業務服務時，我們發現關於“票的分配”存在兩個不同的業務服務：

q分配票給部門協調者；

q分配票給部門員工。

票的分配目標不同，而行為都是分配，是否存在語義不清的問題？實際上，雖然都是對票的分配操作，但它們的業務含義與服務價值完全不同。獲得票的部門協調者並非票的擁有者，不會參加培訓，而是擁有了分配票的資格，可以將票進一步分配給員工。為避免混淆這兩個概念，可以將分配票給部門員工的操作視為對員工的提名。這就明確了如下概念。

q分配票給部門協調者：獲得票的員工為部門協調者，並非參加培訓的員工。

q提名部門員工：將票分給部門員工，使得他（她）具備了參加培訓的資格。

雖然都是部門員工，但是在分配票和培訓的不同業務場景中具有不同的身份。明確這些身份（角色），可以更加準確地體現部門員工與培訓的不同關係。

q候選人：利用過濾器篩選或直接添加的員工，都是培訓的候選人。這些候選人具備被培訓專員或協調者提名參加培訓的資格，但並不意味着候選人已經被提名了。

q 被提名人：指獲得培訓票要求參加培訓的員工，即被提名的對象。

q備選人：指備選名單中的員工，備選名單是提名候選名單中剔除掉被提名人的員工列表。

q學員：被提名人在收到培訓票後確認參加，就會成為該培訓的學員。

無論是明確“分配”的含義，還是進一步細化部門員工的不同身份，都是在定義和提煉統一語言。這些統一語言的確定需要即刻反映在業務服務圖中。

票的取消業務服務圖如圖20-24所示。

不同參與者的取消流程雖然不同，但在業務服務圖中，實際要執行的業務服務都是“取消票”。培訓專員和系統都可以處理票，區別在於一個是人工，一個是自動，後者的觸發條件與觸發時機相對比較複雜。對這些領域邏輯的描述可以在領域建模階段通過業務服務規約進一步細化。

獲得提名並參加培訓的部門員工稱為“學員”，如此可以更好地體現其身份。培訓的業務服務圖如圖20-25所示。

培訓業務規則規定，如果學員沒有提交培訓請假申請或請假申請未通過，卻未曾參加培訓且未簽到，會被視為缺勤。在培訓流程的服務藍圖中，根據業務規則，缺勤學員會被放入黑名單，然而這一活動並未在業務服務圖中體現出來。這是因為學員被加入黑名單實際是“確認缺勤名單”業務服務產生的一個結果，並非一個獨立的業務服務。

分析EAS的業務需求時，從業務流程到業務場景，再從業務場景到業務服務，應該是一個水到渠成的過程。在這個過程中，最好能引入“現場客戶”（極限編程中的一個實踐），共同探索業務需求，梳理出問題空間的業務需求全貌。

為了避免分析癱瘓，在全局分析階段，業務需求分析在獲得業務服務這個粒度時就可以結束，進入架構映射階段。然而，對業務服務做進一步細化仍然屬於需求分析的過程，與開發團隊開展架構映射屬於兩個並行不悖的工作，細化獲得的業務服務規約也將作為領域建模階段的重要輸入。因此，需求分析人員也可在全局分析階段針對核心子領域的業務服務編寫業務服務規約。

組成EAS全局分析規格說明書的業務需求如下所示。

1 業務流程

包括EAS的核心流程與各個具體的業務流程，可通過業務流程圖或服務藍圖呈現。前文已述，現略去。

2 業務場景和業務服務

針對每個具體的業務流程，按照業務目標進行劃分，獲得每個具體的業務場景，並按照業務服務的判斷標準識別業務服務，通過業務服務圖呈現出來。前文已述，現略去。

3 業務服務規約

對每個業務服務進行細化，獲得業務服務規約。

3.1 客戶合作

3.1.1 市場需求管理

（1）創建市場需求

服務編號：EAS-0001

服務描述：

　　作為市場人員

　　我想要創建一條市場需求

　　以便隨時了解市場需求的狀態

觸發事件：

　　市場人員輸入市場需求，點擊“創建”按鈕

基本流程：

1．驗證輸入的市場需求，包括需求名稱、描述、客戶、備註

2．按照規則生成市場需求編號

3．驗證市場需求名稱是否已經存在

4．創建市場需求

替代流程：

1a．當市場需求名稱在系統中已存在，給出提示信息

4a．若市場需求創建失敗，給出失敗原因

驗收標準：

1．市場需求的名稱只能為中文、英文或數字，長度不超過50個字符，不能重複

　　　2．輸入的市場需求中，必須包含市場需求名稱、描述和客戶，客戶為系統已有客戶，備註為可選

3．市場需求編號規則為：EAS-客戶ID-自增長數，市場需求編號不允許重複

4．市場需求被成功創建

3.1.2 合同管理

（1）歸檔合同

服務編號：EAS-0011

服務描述：

作為市場人員

我想要對合同進行歸檔

以便保存合同副本，避免合作糾紛

觸發事件：

市場人員選擇合同文檔，點擊“上傳”按鈕

基本流程：

1．驗證文檔類型的有效性

2．上傳合同文檔

3．保存合同文檔

4．更新合同信息

替代流程：

1a．若上傳的文檔類型並非PDF文檔，給出提示信息

2a．若上傳的文檔超出系統規定的文件大小，給出提示信息

3b．若上傳合同文檔時，文件傳輸失敗，給出失敗原因

4a．更新合同信息失敗，給出失敗原因

驗收標準：

1．歸檔的合同文檔只能為PDF文件，可僅驗證文檔文件的擴展名

　2．服務器歸檔主文件夾為contract/archive，歸檔保存時，需驗證該文件夾是否存在，如果不存在，需要創建該文件夾

3．為合同歸檔文件創建子文件夾，子文件夾名為合同ID

4．若歸檔時，在指定文件夾中已有同名文件存在，則為“另存為”操作，當前文件名增加“（1）”作為後綴

5．合同的歸檔文件屬性添加歸檔文件夾路徑

……

3.3 項目管理

……

3.3.3 項目成員管理

（1）添加項目成員

服務編號：EAS-0105

服務描述：

作為項目管理者

我想要添加項目成員

以便管理項目成員

觸發事件：

項目管理者選定員工和項目角色，點擊“添加”按鈕

基本流程：

1．驗證員工是否工作在其他項目

2．將員工加入項目團隊，成為項目成員

3．修改員工的工作狀態

4．發送郵件通知員工

5．為員工簡歷追加項目經驗

替代流程：

1a．選定員工如果已經加入其他項目，給出提示

2a．添加員工失敗，給出錯誤信息

5a．若員工已具備該項目經驗，則忽略

驗收標準：

1．選定的員工應為“on bench”狀態

2．員工被加入項目團隊後，狀態應變更為“項目中”

3．員工簡歷中的項目經驗信息不能重複

4．員工簡歷中的項目經驗包括：項目名稱、項目描述、擔任的項目角色

3．劃分子領域

全局分析階段對問題空間的識別也是對客戶痛點與系統價值的識別。之所以要開發目標系統，就是要解決客戶的痛點，並為客戶提供具有業務價值的功能。在識別痛點與價值的過程中，需要始終從業務期望與願景出發，與不同的利益相關者進行交流，如此才能達成對問題空間的共同理解。

對EAS而言，集團決策層要解決“供需平衡”這一根本的痛點，就需要及時了解當前有哪些客戶需求、目前又有哪些人力資源可用，這就需要打破市場部、人力資源部和項目管理部之間的信息壁壘，對市場需求、人力資源、項目的信息進行統計，提供直觀的分析結果，進而根據這些分析結果為管理決策提供支持。我們需要就這幾個主要部門了解部門員工的痛點和對價值的訴求。

市場部員工（市場人員）面臨的痛點是無法通過人工管理的方式高效維護與客戶的良好合作關係，故而其價值訴求就是提高客戶關係管理的效率，使得能夠快速地響應客戶需求，敏銳地發現潛在客戶，掌握客戶動態，進而針對潛在客戶開展針對性的市場活動。市場部員工希望能夠建立快速通道，及時明確項目承擔者（即子公司）是否能夠滿足客戶需求，降低市場成本。市場部門還需要準確把握需求的進展情況，跟進合同簽署流程，提高客戶滿意度。

人力資源部員工（招聘專員）的痛點是需要制訂合理的招聘計劃，使得聘用的人才滿足日益增長的客戶需求，又不至於產生大量的人力資源閑置，導致集團的人力成本浪費。站在精細管理的角度考慮，從潛在的市場需求開始，招聘專員就需要與市場部、子公司共同確定招聘計劃。制訂計劃的依據在於潛在的人力資源需求，包括對技能水平的要求、語言能力的要求，同時也需要考慮目前子公司的員工利用率，並參考歷史的供需關係來做出儘可能準確的預測。員工的技能是一種重要的輸出資源，人力資源部需要針對客戶對人員能力的要求制訂培訓計劃，在企業內部組織員工培訓，提升員工技能，如此就能以最小成本輸出最大的人力資源價值。因此，人力資源部的價值訴求就是讓招聘與培訓具有計劃前瞻性與精確性，更好地在客戶需求與人力資源之間維護供需的平衡。

項目管理部負責企業的“生產管理”，對項目以及項目成員的管理直接關係到客戶滿意度。在沒有EAS之前，市場部的苦惱是不了解已簽合同的項目執行情況，即使市場部主動與項目管理部進行溝通，項目管理部也無法提供精確的項目信息，更談不上及時了解項目的進度情況。因此，市場部的價值訴求是了解項目進度以促進與客戶的良好合作關係，而項目管理部的價值訴求是及時了解項目過程執行情況，發現不健康的項目，通過項目管理手段規避延遲交付甚至交付失敗的風險，提高項目的成功率。

識別了痛點與價值，即可藉此劃分子領域細分問題空間。並通過識別核心子領域、通用子領域和支撐子領域來區分核心問題和次要問題。

由於EAS是為軟件集團應用信息化服務的，我們可以在識別出痛點與價值的基礎之上，從業務職能與業務概念相結合的功能分類策略確定整個問題空間的子領域，由此獲得的核心子領域如下：

q決策分析；

q市場需求管理；

q客戶關係管理；

q員工管理；

q人才招聘；

q技能培訓；

q項目進度管理。

除了這些核心子領域，諸如組織結構、認證和授權都屬於通用的子領域，每個核心子領域都需要調用這些子領域提供的功能。注意，雖然通用子領域提供的功能不是系統業務的核心，但缺少這些功能，業務卻無法流轉。之所以沒有將這些功能識別為核心子領域，是因為有對問題空間的理解分析。例如，組織結構管理是保證業務流程運轉以及員工管理的關鍵，用戶的認證與授權則是為了保證系統的訪問安全，都沒有直接對“供需平衡”這一業務願景提供業務價值，因而不是利益相關人亟待解決的痛點。

在分辨系統的利益相關者時，服務中心作為參與EAS的業務部門，主要為項目及項目人員提供工位和硬件資源，要解決的是資源分配的問題。這一功能的引入固然可以幫助企業降低運營成本，卻與價值需求中的系統願景沒有直接關係，因此可以將該子領域作為一種支撐子領域。除此之外，消息通知和文件上傳下載也支持了大部分核心領域的執行活動，都屬於獨立的支撐子領域。

EAS的子領域映射圖如圖20-26所示。

劃分子領域分解了問題空間，使得團隊能對EAS達成共同理解，識別出來的各個子領域也將作為解空間形成的架構方案的參考，尤其是系統分層架構的參考。子領域也屬於全局分析規格說明書的一部分。

本文摘錄《解構領域驅動設計》。需要獲取完整電子版可以關注小編，後台私信：“333”獲取。

本書全面闡釋了領域驅動設計（domain-driven design，DDD）的知識體系，內容覆蓋領域驅動設計的主要模式與主流方法，並在此基礎上提出“領域驅動設計統一過程”（domain-driven design unified process，DDDUP），將整個軟件構建過程劃分為全局分析、架構映射和領域建模3個階段。除給出諸多案例來闡釋領域驅動設計統一過程中的方法與模式之外，本書還通過一個真實而完整的案例全面展現了如何進行領域驅動設計統一過程的實施和落地。為了更好地運用領域驅動設計統一過程，本書還開創性地引入了業務服務、菱形對稱架構、領域驅動架構、服務驅動設計等方法與模式，總結了領域驅動設計能力評估模型與參考過程模型。本書提出的一整套方法體系已在多個項目中推廣和落地。

本書適合希望領會軟件架構本質、提高軟件架構能力的軟件架構師，希望提高領域建模能力、打磨軟件設計能力的開發人員，希望掌握業務分析與建模方法的業務分析人員，希望學習領域驅動設計並將其運用到項目中的軟件行業從業人員閱讀參考。