徐昊@ThoughtWorks

讀完需要

6

分鐘

速讀僅需 2 分鐘

1

? ?

前言

領域建模有很多種方法，對于同樣的問題域使用不同的建模手段得到的模型可能也不盡相同。于是我經常聽到這樣一個問題：

怎么才能保證建模的正確性？

這聽起來是個合理的質疑，但實際上卻不是那么有道理。

首先我們需要明白建模的目的是什么？

如果僅僅是為了描畫問題，那么并沒有什么對錯之分——僅僅是立場和角度的差別；而如果是為了企業業務系統而進行建模，那么這個問題應該變為：

如何保證模型能夠支撐企業的運營？

2

? ?

舉例

我想用下面這個例子來簡要的回答一下這個問題。

在開始分析和建模之前，我們需要知道企業業務系統的目的是什么；

而企業業務系統的目的往往跟決策者或者管理的訴求相關。我們現在需要移情到一位管理者身上，看看他的訴求到底是什么。

現在假想你是一家在線電子書店的 COO。突然有一天，有一位顧客向你投訴，說他訂購的書少了一本，并且價錢算錯了，他多給了錢。在你承諾理賠之前，你需要核對一下這位顧客說的是否屬實。那么這個時候你需要知道什么樣的信息才能做出準確的判斷呢？

簡單來說，你需要知道這位顧客訂購了那些書籍，付了多少錢以及書店到底為這個顧客遞送了那些書籍。不幸的是，由于科技不夠發達，你無法直接駕駛時間機器回到從前去親眼看看發生了那些事。但幸運的是，你并不需要這么做，你只需要看看這位顧客的訂單，和網銀的支付記錄以及你們書店交給 EMS 的快遞單存根，就應該知道這些信息了。

你找到了訂單和 EMS 快遞存根。發現這位顧客是在三天前訂購的書，而你們在前天就已經將書郵寄出去了。并在訂單上看到這位顧客一共訂購了 7 本書，但是在 EMS 的快遞存根上，并沒有任何書籍的信息，只有地址，包裹號，郵費和重量什么的信息。這時候你覺得應該去詢問一下配送部門，看看他們做了什么。

在配送部門根據包裹號查到了那個包裹的信息，果然里面只有 6 本書。同時你在包裹部門發現了一張延期交貨單。上面說明由于缺貨，這位顧客另外一本書正在等待發貨。

那么剩下的問題就是支付問題了，從網銀的記錄上看，客戶不含郵費一共支付了 132.5。訂單上顯示的價錢也是 132.5，顯然這位顧客并沒有多付錢。

為了保證準確，你重新從網站上選了這 7 本書，想看看是否也會是這個價錢。但你卻意外的發現，一共只需要 128.3。仔細辨認后，你發現有一本圖書現在是促銷。那么現在的問題是，促銷到底是什么時候開始的？

你到了市場部，市場部給了你一份近期促銷計劃。你發現那本書是昨天才開始促銷的，也就是說在那位顧客在下訂單的時候，促銷還沒有開始。

這個時候，你覺得應該給你的顧客打一個電話致歉，商討如何后續郵寄的問題，并向他說明促銷的事情。

你是否覺得這個 COO 當得有點累呢？這當然是虛構的。但是從這故事里面我們看到什么呢？

任何的業務事件都會以某種數據的形式留下足跡。我們對于事件的追溯可以通過對數據的追溯來完成。

正如上面這個故事里，你無法回到從前去看看到底發生了什么，但是卻可以在單據的基礎上，一定程度的還原當時事情發生的場景。當我們把這些數據的足跡按照時間順序排列起來，我們幾乎可以清晰的推測出這個在過往的一段時間內到底發生了那些事情。

那么為什么這些數據形成的鏈條能夠成幫助我們追溯業務的營運呢？

因為這些數據并不是隨便挑選的。

3

? ?

回顧

如果我們回顧一下你作為 COO 檢查這個疏漏的過程，你首先選擇了訂單和 EMS 快遞存根，換句話說，如果訂單出現差錯，或者 EMS 快遞存根上說明你的確郵寄了 7 本書，那么這個疏漏的責任并不在你。所以這兩個訂單實際上這個你這個企業法律責任的起點和終點。

當你確定這個疏漏的責任在你之后，你選擇審查一些流程執行的結果，比如包裹存根。從而驗證一些主要的業務流程執行的結果是否正確。換句話講，這些數據是支撐你運營體系的關鍵流程的執行結果。

正是由于這些數據是流程執行的結果，它們才使我們可以在不了解流程細節的前提下，對某些突發事件進行追述和分析。

4

? ?

演進

除了上面那個極端的例子（投訴），對于任何一筆正常的經濟往來，我們都需要知道：

如果我付出一筆資金，那么我的權益是什么？

如果我收到一筆資金，那么我的義務是什么？

而這些問題都需要業務系統捕捉到相應的足跡才能夠回答。所以企業的業務系統主要的目的之一，就是記錄這些足跡，并將這些足跡形成一條有效的追溯鏈。

而作為業務分析師的你，則應該知道那些事件在運營上是需要追溯的，這些事件都留下了什么足跡。

這些足跡通常都具有一個有意思的特性，即它們都是時標性對象（moment-interval）。發現這些時標性對象就是建模的起點。對于這些時標性對象稍加整理，我們就得到了整個領域模型的骨干：

在得到骨干之后，我們需要豐富這個模型，使它可以更好的描述業務概念。這時候，我們需要補充一些實體對象。

通常實體對象有三類：人，地點， 物（party/place/thing）。

在這個基礎上，我們可以進一步抽象這些實體，如果參與到各種不同的流程中去，這時候，我們就需要用到角色（role）：

最后再把一些需要描述的信息放入描述對象（description）。

我們就得了應用四色建模方法（color modeling）建立的一套領域模型。

簡要回顧一下上面的過程，不難發現我們建模的次序和重點：

首先以滿足管理和運營的需要為前提，尋找需要追溯的事件。

根據這些需要追溯，尋找足跡以及相應的時標性對象。

尋找時標對象周圍的人／事／物

從中抽象角色

把一些信息用描述對象補足。

由于在第一步中，我們就將管理和運營目標作為建模的出發點。因此，整套模型實際上是圍繞這些“如何有效地追蹤這些目標”而建立的，這樣的模型可以保證模型支撐企業的運營。

5

? ?

附言

幾位同事幫我審校這篇文章的時候，有人問了一個很有意思的問題：為什么你會以一個看上去像極端情況的例子來說明這個建模方法？

以我的經驗來看，對于業務系統有兩個東西是很重要的：可追溯性（traceability）和執行效率（efficiency）。這里的可追溯性是指責任的可追溯性（traceability of liability），而通常都是在一些不太好的事情發生之后，才需要對責任進行追溯。所以想一個相對負面的例子更容易幫助我們找到建模所需要解決的問題。

另外還有位同事說，你的四色方法與 Peter Coad 的四色法并不完全相同。是的，我所介紹的并不是 Peter Coad 的四色法， 我不敢說是發展， 僅僅是對于 Peter Coad 四色的一種變化吧。

原文首發于infoQ：https://www.infoq.cn/article/xh-four-color-modeling/#3970668-tsina-1-2071-4940258fac58681d93622513463cbd0b

- EOF -

想要加入中生代架構群的小伙伴，請添加群合伙人大白的微信

申請備注（姓名+公司+技術方向）才能通過哦！

58 轉轉技術總監駱俊武：一個核心系統 3 萬多行代碼的重構實戰篇

2020-11-09

中臺實踐：數據中臺構建五步法

2020-11-06

為什么說IT科技公司應該留住35歲員工？

2020-11-05

基于大中臺小前臺模式設計高并發電商架構

2020-11-04

喬新亮：CTO 是怎么實現從技術到管理跨越

2020-11-03

混沌工程：蘇寧系統穩定性之道

2020-11-03

為什么要函數式編程

2020-11-02

貝殼找房技術總監肖鵬：高速成長下的技術團隊怎么帶？

2020-11-02

多隆：從工程師到阿里巴巴合伙人

2020-11-10

? ?END ? ?? #架構師必備#感謝您的一鍵三連 點分享點點贊點在看 新人創作打卡挑戰賽發博客就能抽獎！定制產品紅包拿不停！

總結

以上是生活随笔為你收集整理的徐昊：运用四色建模法进行领域分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。