摘要: 本文探索的是一系列把流程圖轉換爲軟件設計的步驟
大致步驟分爲:
- 用戶需求(讀懂原型圖, 消化業務知識)
- 產品功能
- 流程圖
- 領域設計 (彩色建模+ DDD領域模型)
- 知識轉換: 消化業務知識是否成功在於是否能夠把明顯的已知條件轉換爲隱含的有助於軟件設計的條件
- 實體設計/聚合根設計
- 接口交互設計
- 編寫代碼
粗淺理解: 第1,2步不是很熟悉, 這與用戶洽談有關係.因此不是本文的重點; 本文着重是在描述如何在確定了符合業務需求的產品功能以及梳理清楚流程之後如何去根據流程圖建立領域模型.
1. 如何根據業務流程去畫出建立領域模型呢?
這裏可以使用的工具是UML彩色建模
-
紅色: 過程數據(moment interval) 某個過程的產物–用於記錄動作的
它們在未來會轉換成一張或者多張數據庫表,
在系統初始化時通常是空表 -
綠色: 自然數據(party, place, thing) 人? 地點
問題域中涉及到的"參與者(人, 公司等)",
“地點”,“東西(物品,服務)”. 在識別自然數據時
還需要考慮是否引入"角色".
它們在未來也可能會轉換爲一張或多張數據庫表
而且系統初始化時通常會有基礎數據, 也會隨着系統應用而不斷增加記錄
特點: 具有唯一標識, 可以根據這個唯一標識去追蹤它.
(這是領域建模中的實體的概念麼?) -
黃色: 角色數據(role)-- 把綠色的自然數據抽象出來而形成角色
-
藍色: 描述類數據(description)
分爲兩類:一類是概述類, 如爲了方便選擇商品,抽象了品類這個概述性名稱;
二是規則類, 即想使用數據庫表配置的相關規則
它也可能會轉換爲數據庫表, 且在系統初始化時就有內容, 且會不斷改變
它是無唯一標識的
(這是值對象的概念麼)
識別數據的先後順序:
紅 --> 綠, 黃 --> 藍
具體步驟如下:
-
先把流程描述中的名詞畫出來
-
對着業務流程識別出不同的過程(需要考慮全面):
如體檢業務中分爲 開單過程 預約過程, 繳費過程, 進行體檢項目 -
每個過程都應該找出對應的過程數據, 用紅色標識
-
把每個過程數據的關係: 依賴, 聚合, 一對多, 多對多的關係標識出來
-
然後從最核心的過程數據的那個類開始, 即找出關係最多隻想的那個類
先從這個類開始找自然數據 -
這個過程數據上有人蔘與麼?
有人生成它? 或者它被人接收? 識別出來之後 有團體麼? 他們的關係是如何的? 聚合? 一對多? 角色之間可以互換麼?(如果要可能有繼承關係, 如果不用那麼就單獨列出來),
這些人中, 有需要抽象成角色麼? 比如 服務人員可能會換崗麼?這些人需要分成不同角色嗎? 如果是角色, 應該有什麼人來扮演這個角色? -
把步驟5中的核心問題: 有人嗎? 有東西嗎? 有地點嗎? 這些考慮點轉移到另外一個過程數據對應的實體去逐一考慮, 把剩下的所有的過程數據都這樣考慮個遍, 就完成了識別綠色和黃色的任務了
-
接着來考慮描述性數據(即藍色)
分爲概述類和規則類
在流程描述中有哪些類是爲爲了方便用戶使用的有概述功能的?
概述類: 如體檢套餐–> 概述類的名稱, 用來方便用戶選擇體檢項目的
在流程描述中 有哪些規則是適合用數據庫表配置的呢?
規則類: 如積分規則, 折扣規則
用這種方法畫出類圖是比較好畫的
–
2. 這個彩色建模建立出來的實體就是全部麼?
如何識別出聚合根? 哪些是值對象?
**- 何謂聚合根? **
每個聚合都有一個根實體（聚合根，Aggregate Root），這個根實體是聚合所表述的領域概念的主體，外部對象需要訪問聚合內的實體時，只能通過聚合根進行訪問，而不能直接訪問。
-
關於如何尋找聚合根, 這篇文章介紹得很詳細:
http://www.cnblogs.com/netfocus/p/3307971.html
在此引用幾個關鍵點:聚合是用來封裝真正的不變性，而不是簡單的將對象組合在一起；
聚合應儘量設計的小；
聚合之間的關聯通過ID，而不是對象引用；
聚合內強一致性，聚合之間最終一致性；
結合上面的描述個人的理解是:
靜態的類圖可以畫出來, 根據流程識別出用戶意圖,即理解當前的需求和結合接下來的計劃的需求–> 圈出聚合根, crud操作都是通過聚合根的id去導航而操作, 而非直接對聚合根內的非聚合根實體去操作–> 定接口(這就是所謂的領域服務麼?)–> 設計交互過程: 設計的一些技巧(設計模式應該用到的技巧, 比如工廠模式, 裝飾者模式等等, 因此而變得鮮活)–> 這些都體現在很多優秀的開源項目中, 其源碼的都寫法都是遵循設計的,而最終都是源於這個開源項目想要實現什麼樣的功能.這種類型的項目就是高級項目, 就是類似於Apache社區所支持的項目,
總體思路就是以上這個過程, 其中關鍵的關鍵在於如何定出聚合根,符合業務需求或者項目的目標的聚合根.而業務需求難度在於人與人之間的溝通難點是否清晰, 含混不清的需求定義增大難度.能夠闡述清晰這些業務需求的定義, 有個共同的業務術語系統, 會有助於項目初期階段進行, 這一步界定也是最關鍵的, 畢竟需求不準確, 後續麻煩就多了. 一旦這些界定清晰了, 接下來就是聚合根內部的實體應該如何組織成爲一個整體了, 而組織方法關鍵是看如何合理地運用23種設計模式了, 這其中的過程也挺有趣的. (其中用得最多的就是用工廠模式去組織聚合根)
聚合根的概念是跟用戶意圖有關, 即跟需求有關. 它是不是可以這樣那樣聚合, 就跟用戶是否要查詢它出來非常相關.
(用戶需求可以被拆分成一個個用戶意圖,)
用戶意圖用戶需求就決定這個聚合根如何去劃分.
什麼樣的實體或者值對象會被劃分到同一個聚合裏面組成聚合根呢?
–
- 關於業務建模
對於toB的業務建模是站在企業的視角去考慮問題, business need是最主要驅動力
而互聯網思維是站在個人需求的角度上, 難度比ToB的大大增加,對於併發的要求很高, 而Apache社區的項目的目標就是服務這種類型的.
–
- 關於技術的進階
讀論文, 得啃.
4.如何確定業務流程
- 業務流程名稱
- 流程簡要說明: 描述流程的起點和終點以及目標概述
- 業務流程描述, 選擇合適的模型呈現業務流程的分析結果.
流程圖的六個要素:
分工, 活動, 協作, 產物關係, 分支, 審批
- 具體的實例可以參考以下鏈接
- http://www.cnblogs.com/daoqidelv/p/7657785.htm
參考資料
http://www.cnblogs.com/netfocus/p/3307971.html
<UML彩色建模>
http://www.cnblogs.com/daoqidelv/p/7657785.htm
<領域驅動設計：軟件核心複雜性應對之道>
<實現領域驅動設計> 美 弗農著