作者: Kent & Chris? 來源: InfoQ? 發布時間: 2013-12-17 18:21
英文原文：The Seven Information Smells of Domain Modelling
領域建模（Domain modelling ）作為一項強大的技術，常備于很多IT專業人士的工具箱之中。令人遺憾的是，在過去的幾年間，因為領域建模的幾個問題導致人們對其大失所望，尤其是在敏捷領域。這種方式的兩個切實存在的問題就是：它會消耗太長的時間并且很易于導致“分析癱瘓（analysis paralysis”），而這會導致停滯（“spinning wheels”）。我們為領域建模提供了一種方式，可以用來解決這些問題。
我們會討論領域模型中的一些信號，這些信號會告訴你要提出更多的問題。我們將這些信號稱之為“壞味道信息（information smells）”，它們會提醒我們可能并沒有完全理解領域模型所關注的信息。這些壞味道可能意味著我們在領域模型中丟失了信息或者領域模型中包含了不正確的信息。關注于壞味道信息會引導我們發現需要回答的問題，這是一個很快的過程。當所有的壞味道都消失掉或者能夠確認剩余的都是可接受的，我們就會停止，這會避免分析癱瘓。
這個過程開始于系統的輸出，這些輸出會為用戶交付價值。我們在本文中不會闡述如何尋找這個價值。接下來，我們基于輸出來處理模型中的這些壞味道信息。
為了闡述本文中的信息壞味道，我們會使用一個虛擬的例子，這個例子來源于多個現實生活中的場景。我們的人力資源主管想了解各種開發人員的薪酬是如何支付的，這樣他們就能避免在不同群體間進行不公正的支付所導致的法律糾紛。
在隨后進行的討論中，團隊試圖理解主管的要求時，產生了如下的草圖：
領域建模最好的工具就是筆和紙或者記號筆和索引卡片或者白板筆和白板，因為它會將關注的焦點放在要交換的信息上，而不是試圖將樣例或模型變得“看上去很漂亮”。也就是說，為了防止我們凌亂的筆跡讓您暈頭轉向，我們使用圖形化工具來創建了模型。因此，以下就是這個樣例的更整潔版本：
關于壞味道信息以及它們對領域模型所反映出來的內容，有很重要的幾點需要我們記住：
壞味道信息并不一定表明就是一個問題。
壞味道信息是可能存在問題的強烈信號。
壞味道信息并不像規則那樣具有強制性，規則通常都是正確的。
對于壞味道信息所反映出的問題應該按照“請給我一個……的例子”的形式來進行闡述，而不是“告訴我如何……”的形式。我們會探索領域細節的樣例而不是對模型進行泛化（generalisation），從而對細節進行隱藏。
閑言少敘，以下就列出了主要的壞味道信息。如果你發現了其他的場景，請告訴我們以便讓更多的人知道。
某個條目在輸出中，但是不在模型之中。
某個條目在模型之中，但是不在輸出中。
兩條信息位于同一個地方。
某個實體與任何其他的實體都沒有關聯。
一對一關系。
多對多關系。
未定義的功能。
以下更為詳細地描述了每一種壞味道信息。
壞味道信息#1 – 某個條目在輸出中，但是不在模型之中。
輸出中的所有條目都需要存在于領域模型之中。輸出只是對模型中數據的展現。輸出中展現的每條信息都應該是模型中的一個屬性或方法。在上面的例子中，模型中缺失了部門、平均工資、角色、工資、性別以及種族。為了消除這個壞味道，將它們作為屬性或方法添加進來。如果缺失添加這些信息的合適實體，那需要添加實體。
壞味道信息 #2 – 條目在模型中，但是不在輸出之中。
條目位于模型之中，但是并不在輸出中是分析過程里面“推（push）”的一個例子。分析師認為它們需要這個值，而實際上卻并不是這樣。他們將值推到了模型之中。這會是比較危險的，因為你最終可能需要額外的開發來添加和維護這個值。但這是一種壞味道，它可能會被添加進來因為分析師覺得它是有用的。為了解決掉這種壞味道，我們需要問一下用戶是否需要這個信息。注意，對于分析師來說這是過程的一種分解，因為他們需要將對用戶的問題記錄在問題日志中，而不是在模型之中。這種情況可能會發生在這樣的場景之中，另外的一個項目需要一些信息，因此它就“悄然引入（slip）”到需求中來了。這些額外的需求應該作為單獨的一項任務來處理。
在結構化系統分析與設計方法（Structured Systems Analysis and Design Method，SSADM）中，這被稱之為“信宿（Information Sink）”。
壞味道信息 #3 – 兩條信息位于一個地方（1NF）
將兩條信息放在一個地方會引起混亂。名字“John Smith”可以按照名和姓進行存儲。但是，這是一種壞味道。在一些場景之中，將名字存在一個地方是合適的，但在另一些場景中卻不是這樣。關鍵的問題在于，你是不是需要獨立地分析或處理這兩個信息條目。通常情況下，這被稱之為違反“第一范式（First Normal Form）”或1NF。盡管1NF確實是一項設計規則，但是它也可以指導我們發現兩條不同數據的實際指向是同一個。違反第一范式通常會通過查看真實的數據來識別，因為數據一般會借助名字來進行引用。另外一個樣例就是種族（Race），它包含了“Jedi”（一個信仰/宗教）以及“IC1”（英國警方所使用的種族分類）。
壞味道信息#4 – 沒有關聯
系統中的業務對象應該是連接起來的。當你無法識別兩個業務對象之間的關系時，你需要詢問用戶一個重要的問題：這兩件事之間的關聯是什么？是直接關聯嗎？還是通過其他的事情？
這是一個很嚴重的壞味道。根據經驗判斷，這通常會導致信息的丟失。在企業級系統中，缺失的通常是組織化的結構。
壞味道信息 #5 – 一對一關系，它們是不是同一件事？
當你遇到一對一關系時，通常會有兩種可能的解釋。第一，業務人員用多個術語表達相同的事情，因此兩個業務對象實際上應該是一個對象。第二，一對一關系實際上應該是一對多關系，但是你并不知道原因。例如，汽車和司機可能是一對一的關系，但是當你深入挖掘的時候，你會發現同一時間一輛汽車只能由一位司機進行駕駛。眾多的司機可以在不同的時間駕駛同一輛汽車。這里缺失的信息就是關系的暫時性特征。
壞味道信息 #6 – 多對多（缺失信息）
多對多關系有時候會表達合理的關系。但大多數的時候，它們表明缺失了“連接的（link）”業務對象。在關系型軟件設計中，多對多關系會用連接實體（link entity）來取代。連接實體通常也是一個業務對象，它具有關于關系本身的信息。在上面的例子中，一個雇員在不同的時間里面（暫時性的）會有多個工作頭銜或者他們會將自己的時間花費在多個角色上。再次強調一遍，這種壞味道信息會幫助我們跟蹤潛在的信息缺失。
壞味道信息 #7 – 未定義的功能（缺失信息）
模型中的每個方法都應該進行定義。方法中引用的任何事情都應該在業務模型之中。以getAge為例：
getAge按照年份來計算年齡：
getAge = (today() – Employee.date of birth) / 365
出生日期和獲取當前日期的功能缺失了。它們應該被加到業務模型之中。
總結一下，過程是這樣的：
識別會給用戶交付價值的輸出。
如果你還沒有支持這個輸出的領域模型，那就創建一個。
檢查模型中的壞味道信息，直到它們不再存在。
停止。
這種方式會比傳統的領域建模快得多并且更加專注。你采用領域建模卻不會陷于“停滯（spinning your wheels）”的狀態會令你的朋友感到吃驚的。
側邊欄（Sidebar） - 領域模型
領域模型是組織中某個方面的簡化，可能是產品、運作或者是市場。領域模型是特定于組織及其工作方式的。盡管模型可能會使用業界標準的術語，但是模型會為特定的組織及其環境創建明確的詞匯表。領域模型通常會描述從事這項業務的人所關心的信息。鑒于大多數的業務系統主要關注于收集、處理以及提供數據，所以可以順理成章地說，了解信息是什么并且以一種清晰的方式來對信息進行分類是很重要的。一般來講，領域模型包含業務實體，而業務實體會關聯數據和行為。業務實體之間的交互通常也會進行聲明。領域建模的示例包括實體—關系模型以及對象模型。
側邊欄 - 所使用的例子
我們從HR主管想要得到的報告開始。
壞味道1—某個條目在輸出中，但是不在模型之中。
我們有一些條目在輸出中，但是并不在模型中，所以我們將這些條目添加到模型里面。
注意一下平均工資是基于其他數據計算出來的，所以將其稱之為getAverageSalary以提醒我們這是一個計算所得的屬性。
壞味道 2 – 某個條目在模型中但是不在輸出之中。
有些人沒有管住自己將Birthday添加到Employee之中了。
我們詢問HR主管是否需要在報表中包含Birthday。他們的回答是“不需要”，但是他們想要在報表中包含“Age”。
壞味道 3 – 兩條信息位于同一個位置
名字由名和姓組成。我們詢問HR主管是否想要將其分開，這樣的話他們就能看到具備相同姓的所有人（姓可以用于識別文化群體）。他的回答是并不想這樣。
壞味道 4 –某個實體與其他的所有實體都沒有關聯
模型中所有的實體必須是連接起來的。我們詢問業務方面的專家實體要直接關聯還是要通過其他的實體進行關聯。例如，雇員是與部門直接關聯，還是雇員與團隊關聯，而團隊再與部門關聯。
壞味道 5 – 一對一關聯
一對一關聯是一種壞味道，所以針對這種關系我們要詢問相關的專家。我們并不是直接問雇員和部門之間的關系是什么，因為這只會得到通用的情況。相反，我們應該這樣問，“你能給我某位員工屬于多個部門的例子嗎”以及“你能給我某個部門的員工多于一個人的例子嗎”。
嚴格使用這種技術可能會問出一些看起來很愚蠢的問題，但是這些問題實際上是很有價值的。“你能給我某位雇員有多個性別或多個種族的例子嗎”。通過這些問題識別出來的人很可能正是那些遭受歧視和偏見的人。
我們保持這些問題一直是開放的，直到找到某個樣例為止。它們會作為系統可能會發生變化的風險指示器。
壞味道 6 – 多對多關系
多對多關系可能意味著信息的丟失。我們詢問相關的專家可能丟失的信息是什么。在本例中，雇員的時間被分配到了兩個或更多的部門之中。
在角色、性別以及種族方面，相關的專家并沒有想出任何有額外價值的信息。所以壞味道信息將依然作為開放性的問題，它們指示了一種變化的風險。
一個專業的網站通過建立七種分類（male、female、male pre-op female、female pre-op male、male post-op female、female post-op male、inter-sex）解決了性別中的多對多關系。缺失的信息可能是某個人決定要做手術的日期，或者他們何時做的手術以及這些事情隨后怎樣影響工資增長和獎金。.
壞味道 7 – 未定義的功能
我們詢問相關的專家如何計算getAverageSalary以及getAge。
這會導致將allocation.cost和employee.dateOfBirth的值加入到模型之中。
現在已經沒有未處理或決定延遲處理的壞味道了。我們可以就停止領域建模了。
關于作者
Chris Matts是一位敏捷實踐者，他會做所有必要的事情。因此，他擔當的角色包括項目管理人員、業務分析師、測試人員甚至開發人員（盡管在這方面他做得實在不好）。盡管在過去二十多年的經驗中，他主要在為投資銀行構建交易和風險管理系統，但是他目前擔任Microsoft Skype部門在企業級級別采用敏捷和Real Option的教練。Chris的第一個碩士學位是微電子和軟件工程（Microelectronics and Software Engineering）專業的，而第二個碩士學位是數學交易和金融專業（Mathematical Trading and Finance）的。除了Olav Maassen以及Chris Geary，他還會出版一本關于業務的圖形化小說，將其稱之為“Commitment”。“Commitment”是關于項目風險管理的故事。
Kent J. McDonald幫助很多的組織提高了項目的有效性。他超過15年的經驗包括擔任業務分析師、戰略管理、項目管理以及多種行業的產品開發，這涉及到金融服務、健康保險、績效營銷、人力資源服務、非盈利組織以及汽車行業。他是“Stand Back and Deliver: Accelerating Business Agility”的合作者，目前為B2T Training提供業務分析培訓并且在BeyondRequirements.com站點上分享他在項目有效性方面的想法。
