領域建模有很多種方法，對於同樣的問題域使用不同的建模手段得到的模型可能也不盡相同。於是我經常聽到這樣一個問題：怎麼才能保證建模的正確性？ 領域建模有很多種方法，對於同樣的問題域使用不同的建模手段得到的模型可能也不盡相同。於是我經常聽到這樣一個問題：怎麼才能保證建模的正確性？ 這聽起來是個合理的質疑， ...
領域建模有很多種方法，對於同樣的問題域使用不同的建模手段得到的模型可能也不盡相同。於是我經常聽到這樣一個問題：怎麼才能保證建模的正確性？
這聽起來是個合理的質疑，但實際上卻不是那麼有道理。首先我們需要明白建模的目的是什麼？如果僅僅是為了描畫問題，那麼並沒有什麼對錯之分——僅僅是立場和角度的差別；而如果是為了企業業務系統而進行建模，那麼這個問題應該變為：如何保證模型能夠支撐企業的運營？
我想用下麵這個例子來簡要的回答一下這個問題。
在開始分析和建模之前，我們需要知道企業業務系統的目的是什麼；而企業業務系統的目的往往跟決策者或者管理的訴求相關。我們現在需要移情到一位管理者身上，看看他的訴求到底是什麼。
現在假想你是一家線上電子書店的 COO。突然有一天，有一位顧客向你投訴，說他訂購的書少了一本，並且價錢算錯了，他多給了錢。在你承諾理賠之前，你需要核對一下這位顧客說的是否屬實。那麼這個時候你需要知道什麼樣的信息才能做出準確的判斷呢？
簡單來說，你需要知道這位顧客訂購了那些書籍，付了多少錢以及書店到底為這個顧客遞送了那些書籍。不幸的是，由於科技不夠發達，你無法直接駕駛時間機器回到從前去親眼看看發生了那些事。但幸運的是，你並不需要這麼做，你只需要看看這位顧客的訂單，和網銀的支付記錄以及你們書店交給 EMS 的快遞單存根，就應該知道這些信息了。
你找到了訂單和 EMS 快遞存根。發現這位顧客是在三天前訂購的書，而你們在前天就已經將書郵寄出去了。併在訂單上看到這位顧客一共訂購了 7 本書，但是在 EMS 的快遞存根上，並沒有任何書籍的信息，只有地址，包裹號，郵費和重量什麼的信息。這時候你覺得應該去詢問一下配送部門，看看他們做了什麼。
在配送部門你根據包裹號查到了那個包裹的信息，果然裡面只有 6 本書。同時你在包裹部門發現了一張延期交貨單。上面說明由於缺貨，這位顧客另外一本書正在等待發貨。
那麼剩下的問題就是支付問題了，從網銀的記錄上看，客戶不含郵費一共支付了 132.5。訂單上顯示的價錢也是 132.5，顯然這位顧客並沒有多付錢。
為了保證準確，你重新從網站上選了這 7 本書，想看看是否也會是這個價錢。但你卻意外的發現，一共只需要 128.3。仔細辨認後，你發現有一本圖書現在是促銷。那麼現在的問題是，促銷到底是什麼時候開始的？
你到了市場部，市場部給了你一份近期促銷計劃。你發現那本書是昨天才開始促銷的，也就是說在那位顧客在下訂單的時候，促銷還沒有開始。
這個時候，你覺得應該給你的顧客打一個電話致歉，商討如何後續郵寄的問題，並向他說明促銷的事情。
你是否覺得這個 COO 當得有點累呢？這當然是虛構的。但是從這故事裡面我們看到什麼呢？
任何的業務事件都會以某種數據的形式留下足跡。我們對於事件的追溯可以通過對數據的追溯來完成。正如上面這個故事里，你無法回到從前去看看到底發生了什麼，但是卻可以在單據的基礎上，一定程度的還原當時事情發生的場景。當我們把這些數據的足跡按照時間順序排列起來，我們幾乎可以清晰的推測出這個在過往的一段時間內到底發生了那些事情。
那麼為什麼這些數據形成的鏈條能夠成幫助我們追溯業務的營運呢？
因為這些數據並不是隨便挑選的。如果我們回顧一下你作為 COO 檢查這個疏漏的過程，你首先選擇了訂單和 EMS 快遞存根，換句話說，如果訂單出現差錯，或者 EMS 快遞存根上說明你的確郵寄了 7 本書，那麼這個疏漏的責任並不在你。所以這兩個訂單實際上這個你這個企業法律責任的起點和終點。
當你確定這個疏漏的責任在你之後，你選擇審查一些流程執行的結果，比如包裹存根。從而驗證一些主要的業務流程執行的結果是否正確。換句話講，這些數據是支撐你運營體系的關鍵流程的執行結果。
正是由於這些數據是流程執行的結果，它們才使我們可以在不瞭解流程細節的前提下，對某些突發事件進行追述和分析。
除了上面那個極端的例子（投訴），對於任何一筆正常的經濟往來，我們都需要知道：
- 如果我付出一筆資金，那麼我的權益是什麼？
- 如果我收到一筆資金，那麼我的義務是什麼？
而這些問題都需要業務系統捕捉到相應的足跡才能夠回答。所以企業的業務系統主要的目的之一，就是記錄這些足跡，並將這些足跡形成一條有效的追溯鏈。
而作為業務分析師的你，則應該知道那些事件在運營上是需要追溯的，這些事件都留下了什麼足跡。
這些足跡通常都具有一個有意思的特性，即它們都是時標性對象（moment-interval）。發現這些時標性對象就是建模的起點。對於這些時標性對象稍加整理，我們就得到了整個領域模型的骨幹：
在得到骨幹之後，我們需要豐富這個模型，使它可以更好的描述業務概念。這時候，我們需要補充一些實體對象。通常實體對象有三類：人，地點， 物（party/place/thing）。
在這個基礎上，我們可以進一步抽象這些實體事如果參與到各種不同的流程中去的，這時候，我們就需要用到角色（role）：
最後再把一些需要描述的信息放入描述對象（description）。
我們就得了應用四色建模方法（color modeling）建立的一套領域模型。
簡要回顧一下上面的過程，不難發現我們建模的次序和重點：
- 首先以滿足管理和運營的需要為前提，尋找需要追溯的事件。
- 根據這些需要追溯，尋找足跡以及相應的時標性對象。
- 尋找時標對象周圍的人／事／物
- 從中抽象角色
- 把一些信息用描述對象補足。
由於在第一步中，我們就將管理和運營目標做為建模的出發點。因此，整套模型實際上是圍繞這些“如何有效地追蹤這些目標”而建立的，這樣的模型可以保證模型支撐企業的運營。
附言
幾位同事幫我審校這篇文章的時候，有人問了一個很有意思的問題：為什麼你會以一個看上去像極端情況的例子來說明這個建模方法？ 以我的經驗來看，對於業務系統有兩個東西是很重要的：可追溯性（traceability）和執行效率（efficiency）。這裡的可追溯性是指責任的可追溯性（traceability of liability），而通常都是在一些不太好的事情發生之後，才需要對責任進行追溯。所以想一個相對負面的例子更容易幫助我們找到建模所需要解決的問題。
另外還有位同事說，你的四色方法與 Peter Coad 的四色法並不完全相同。是的，我所介紹的並不是 Peter Coad 的四色法， 我不敢說是發展， 僅僅是對於 Peter Coad 四色的一種變化吧。
閱讀數：226852011 年 11 月 7 日 00:00
