這聽起來是個合理的質疑，但實際上卻不是那麼有道理。首先咱們須要明白建模的目的是什麼？若是僅僅是爲了描畫問題，那麼並無什麼對錯之分——僅僅是立場和角度的差異；而若是是爲了企業業務系統而進行建模，那麼這個問題應該變爲：如何保證模型可以支撐企業的運營？spa
我想用下面這個例子來簡要的回答一下這個問題。對象
在開始分析和建模以前，咱們須要知道企業業務系統的目的是什麼；而企業業務系統的目的每每跟決策者或者管理的訴求相關。咱們如今須要移情到一位管理者身上，看看他的訴求究竟是什麼。blog
如今假想你是一家在線電子書店的 COO。忽然有一天，有一位顧客向你投訴，說他訂購的書少了一本，而且價錢算錯了，他多給了錢。在你承諾理賠以前，你須要覈對一下這位顧客說的是否屬實。那麼這個時候你須要知道什麼樣的信息才能作出準確的判斷呢？事件
簡單來講，你須要知道這位顧客訂購了那些書籍，付了多少錢以及書店到底爲這個顧客遞送了那些書籍。不幸的是，因爲科技不夠發達，你沒法直接駕駛時間機器回到從前去親眼看看發生了那些事。但幸運的是，你並不須要這麼作，你只須要看看這位顧客的訂單，和網銀的支付記錄以及大家書店交給 EMS 的快遞單存根，就應該知道這些信息了。ip
你找到了訂單和 EMS 快遞存根。發現這位顧客是在三天前訂購的書，而大家在前天就已經將書郵寄出去了。並在訂單上看到這位顧客一共訂購了 7 本書，可是在 EMS 的快遞存根上，並無任何書籍的信息，只有地址，包裹號，郵費和重量什麼的信息。這時候你以爲應該去詢問一下配送部門，看看他們作了什麼。ci
在配送部門你根據包裹號查到了那個包裹的信息，果真裏面只有 6 本書。同時你在包裹部門發現了一張延期交貨單。上面說明因爲缺貨，這位顧客另一本書正在等待發貨。get
那麼剩下的問題就是支付問題了，從網銀的記錄上看，客戶不含郵費一共支付了 132.5。訂單上顯示的價錢也是 132.5，顯然這位顧客並無多付錢。it
爲了保證準確，你從新從網站上選了這 7 本書，想看看是否也會是這個價錢。但你卻意外的發現，一共只須要 128.3。仔細辨認後，你發現有一本圖書如今是促銷。那麼如今的問題是，促銷究竟是何時開始的？io
你到了市場部，市場部給了你一份近期促銷計劃。你發現那本書是昨天才開始促銷的，也就是說在那位顧客在下訂單的時候，促銷尚未開始。
這個時候，你以爲應該給你的顧客打一個電話致歉，商討如何後續郵寄的問題，並向他說明促銷的事情。
你是否以爲這個 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