領域建模有很多種方法，對於同樣的問題域使用不同的建模手段得到的模型可能也不盡相同。於是我經常聽到這樣一個問題：怎麼才能保證建模的正確性？
這聽起來是個合理的質疑，但實際上卻不是那麼有道理。首先我們需要明白建模的目的是什麼？如果僅僅是爲了描畫問題，那麼並沒有什麼對錯之分——僅僅是立場和角度的差別；而如果是爲了企業業務系統而進行建模，那麼這個問題應該變爲：如何保證模型能夠支撐企業的運營？
我想用下面這個例子來簡要的回答一下這個問題。
在開始分析和建模之前，我們需要知道企業業務系統的目的是什麼；而企業業務系統的目的往往跟決策者或者管理的訴求相關。我們現在需要移情到一位管理者身上，看看他的訴求到底是什麼。
現在假想你是一家在線電子書店的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）建立的一套領域模型。
簡要回顧一下上面的過程，不難發現我們建模的次序和重點：
- 首先以滿足管理和運營的需要爲前提，尋找需要追溯的事件。
- 根據這些需要追溯，尋找足跡以及相應的時標性對象。
- 尋找時標對象周圍的人／事／物
- 從中抽象角色
- 把一些信息用描述對象補足。
由於在第一步中，我們就將管理和運營目標做爲建模的出發點。因此，整套模型實際上是圍繞這些“如何有效地追蹤這些目標”而建立的，這樣的模型可以保證模型支撐企業的運營。
----------
四色建模法(Color UML)是由Peter Coad 發明的一種建模方法，將抽象出來的對象分成四種原型（archetype）：
1、moment-interval,這種對象表示那些在某個時間點存在，或者會存在一段時間的，這樣的對象往往表示了一次外界的請求，比如一次詢價（Quotation），一次購買（Sale），這樣的對象表示的都是系統的價值所在，所以也是最重要的一類對象，一般用粉紅色來表示。這樣的對象一般都有一個起始時間和終止時間，以及一個唯一的標識號，用來唯一的標識這一次客戶請求，比如PolicyNo.
2、Role， 這種對象表示的是一種角色，往往由人或者物來承擔，會有相應的責任和權利，一般一個moment-interval對象會關聯多個Role,比如說一次詢價（Quotation）涉及到兩個Role, 詢價人（Quoter）和詢價的產品（Product for Quotation）, 這類對象是除moment-interval對象外最重要的一類對象，一般用黃色來表示。這類對象一般都有一些被moment-interval對象請求的操作，用來完成它們的職責。
3、 Party,Place, or Thing, 這種對象往往表示的是一種客觀存在的事物，例如：人，組織，產品，配件等等，這些事物往往會在一種moment-interval 中扮演某個Role, 比如某個人會在一次購買中扮演Customer的角色，也可以在詢價中扮演詢價人的角色。這類對象第三重要，所以一般用綠色來表示。這類對象一般都有Name,Address等屬性。
4、Description，這種對象一般是分類用或者描述性的對象，一般某個Thing,Place，Party會屬於某個Description，主要用來表示一類事物，它的屬性一般都是這一類事物都有的屬性，這類對象一般用藍色來表示。這類對象一般都有type,defaultValue等屬性。
通過將分析得到的領域對象分別歸入這四類原型，能讓我們更加深刻的理解每個對象的職責，以及對象之間的相互關係，通過四種顏色，能表達出比一般的黑白模型更加豐富的領域信息。
四色建模法和別的建模方法相比，更傾向於作爲一種分析方法，而不是設計方法，它也可以看作是一種分析模式，和Martin Fowler的《分析模式》有異曲同工之妙。在《Java Modeling in Color with UML》這本書中，Peter Coad給出了多個行業的通用對象模型，包括製造業，資源管理，人力資源管理，財務管理等等，當然都是用四色建模法表示的，確實有耳目一新之感。
原文出自：http://www.infoq.com/cn/articles/xh-four-color-modeling