評點張逸觀點（2）對問題域（Problem Domain）的誤用

• 2019 年 10 月 6 日
• 筆記

我看到張逸老師在最近的一些文章中喜歡提「老」字，例如：

「我充分借鑒了事件風暴這種新方法，卻又未完全拋棄UML這種老方法」

「若有可能，我還希望再加上一個ICONIX方法，雖然它已經垂垂老矣，但該方法蘊含的一些設計思想仍有值得借鑒之處」

張逸老師的關注點從編碼拓展到軟體開發的全部工作流，值得稱讚。不過每個工作流有各自的技能需要學習，是自己的感悟還罷了，如果要傳授技藝給他人，更需要高標準嚴要求才對。

所以，我就用建模思維剖析張逸老師近期發表的一些內容，供大家參考。

就先從張逸老師上面這兩句話開始吧。

一、不是什麼都叫「方法」

上面這兩句話，張逸老師對各種概念一律以「方法」稱呼之。其實UML是「Unified Modeling Language」，是「語言」，或者「表示法」（Notation）。

ICONIX則是Doug Rosenberg等人提出的一種使用UML的建模過程（Process）。我們先來看2001年的著作：

圖1 摘自Rosenberg, D., Scott,K., Applying Use Case Driven Object Modeling with UML: An Annotated e-CommerceExample. Addison Wesley (2001)

再來看2007年的著作：

圖2 摘自Rosenberg, D., Stephens,M., Use Case Driven Object Modeling with UML: Theory and Practice. Apress (2007)

關於方法、過程和工具的定義，可以參照被廣泛使用的教材「Software Engineering: A Practitioner's Approach」，2014出了第8版。

圖3 摘自Pressman R.,Maxim B., Software Engineering: A Practitioner's Approach 8th Edition. SEM(2014)

我於2008年寫的《四十年軟體工程故事》（http://www.umlchina.com/book/se40.htm）也可以參考。

為什麼對這些不當用詞如此重視，我在《為什麼要對術語"吹毛求疵"》一文（http://www.umlchina.com/qa/Content/906.htm）中闡述了我的觀點：

我們聽到有人像上面的姨媽表哥一樣說話時，我們心裡知道，這可不是什麼習慣用語不同，而是說話的人是外行。因為我們是內行，我們比姨媽表哥們更知道一些概念之間的區別。

同理，如果我們真的弄懂了軟體開發中的一些重要概念，當有人在我們面前說"功能模組"、"用戶需求"、"設計階段"等術語時，我們心裡就知道了，這不是什麼習慣問題，而是這個人在某些方面是個外行。

二、關於「老」

人們對事物的認識會不斷深入，所以，已有的知識有的會被繼承，有的會被淘汰。但是要注意，之所以某些知識會被淘汰，是因為人們針對這方面的知識有了更深刻的認識，而不是因為法律規定這個知識只有「**年**權」，到時間就要強行作廢。幾百年前的數學、物理知識，大部分我們今天不還在繼續學習和使用嗎？

圖4 摘自《中華人民共和國城鎮國有土地使用權出讓和轉讓暫行條例》

既然張逸老師說「UML」、「ICONIX」老、垂垂老矣，那我請問張逸老師，能否具體說說看UML、ICONIX到底有哪些缺點，看看能不能說到位？但願不是為了強調自己的「新」而隨口一說。

我不認為UML這個建模語言是完美的，也不認為ICONIX這個過程的做法有多好。我甚至認為經過將近20年的積累，對於建模和UML的下一步改進，我的認識也許比起很多國外的人士更深刻。我還相信我在《軟體方法》中提倡的過程比ICONIX（以及其他一些類似過程）要更高效實用。

不過，絕大多數軟體開發人員基本上是「赤手空拳」，根本沒有達到被UML的不完美和ICONIX的不足絆倒的地步。事實上，就算有人不使用UML里的圖，能熟練使用數據流圖和實體關係圖建模，或者把能把ICONIX那幾招用熟，我覺得他就已經高出周圍的人一大截了。

NBA的格林可能清楚詹姆斯有啥缺點，但這對業餘球員來說有多少參考價值？

癌症的化療、放療有局限性和副作用，是需要有更好的治療手段，但方嚮應該是更精細的免疫治療，而不是拿幾味中藥湊一湊得出來的「癌必靈」。

三、「痛點」離「問題域」還有多遠

圖5 摘自張逸文章《領域驅動戰略設計暨微服務設計工作坊》

「域」是一個面積或範圍較大的概念，「點」是面積或範圍很小或近似於零的概念，兩者不能等同。

也許張逸老師要表述的意思是：通過痛點來判斷哪一塊領域需要建模。就像在人體按下痛點來判斷哪一塊區域需要深入研究。這樣的表述更容易理解一些。

即使換了表述，也還是不準確，因為從「痛點」到領域模型，還有一段距離。「頭痛」的問題未必在頭。

先列舉一些建模知識點，更詳細內容請參見《軟體方法》。

通過下面例子來說明問題。某醫院現在有個「痛點」：輸液反應的投訴比往年多了。

這個「痛點」和需要改進的範圍不是一一對應的。

【可能原因一】

有人組團碰瓷。

【改進方案】

1.1 引進一批記憶力好的高級保安（業務工人）盯牢每一個患者，發現可疑人員報警，如圖6。

圖6 改進方案1.1，引進業務工人

1.2 如果一定要「資訊化改進」，可以應用改進模式三「封裝領域邏輯」，引進一套人物特徵識別系統（業務實體），把「監控人物特徵」的邏輯從高級保安的大腦轉移到人物特徵識別系統，並爭取和公安部門的業務實體對接。一旦檢測到碰瓷黨到來，直接報警並通知挂號員，如圖7。

圖7 改進方案1.2，業務實體替換業務工人

由圖7可以映射出「人物特徵識別系統」的用例圖，也就是用例級別的需求，如圖8。補充上用例的涉眾利益、路徑、步驟、補充約束，就得到完整的系統用例規約，即以用例為組織形式的需求規約。

圖8 人物特徵識別系統的用例圖

可能有的人會問，這個系統應該還有其他用例吧？例如有個人用這個系統來設置一下規則？可能有，也可能沒有（讀者可以想一想，為什麼可能沒有？）。不過再有100個也不影響，因為每次迭代只需要關注最重要的用例，永遠都在路上。

如果某個已有的非人智慧系統已經提供了這個用例，評估過後覺得確實滿足需求的約定，那事情到此為止，不用操心後面的分析設計工作流了。

如果沒有現成的可用，還是要做，那就開始分析工作流。

只要構造出來的系統履行了需求的約定，按照哪種分析設計方法學來構造系統都可以。如果用面向對象分析設計方法學來構造系統，我們假設系統由「對象」這樣一種東西構成。在分析工作流，系統中的對象在一個虛的"對象空間"中運行。這個空間不是記憶體，也不是硬碟，只是人腦中的一個邏輯空間。

可能的分析類圖如下：

圖9 人物特徵識別系統的分析類圖（不熟悉這個領域的邏輯，僅屬猜測）

【可能原因二】

中國逐漸進入老齡社會，老年輸液患者的人數越來越多。

【改進方案】

2.1 不改進，主管部門理解就行。

2.2 在內部下密令，醫生開醫囑時，留心看一眼HIS系統里的患者資料。針對老年患者開醫囑時，盡量不要有輸液內容，如圖10。

圖10 改進方案2.2-讓醫生（業務工人）判斷是否老年患者

2.3 如果一定要「資訊化改進」，可以應用改進模式三「封裝領域邏輯」，在現有HIS系統里添加一些邏輯，醫生在給老年患者開醫囑時，HIS系統提醒一下，如圖11。

圖11 改進方案2.3-HIS判斷是否老年患者

HIS系統已有的用例「開醫囑」中，會多一些步驟（判斷是否老年患者、提醒醫生……）和補充約束（判斷老年患者規則）。HIS系統內部可以不增加新的類，可以在原有「患者」類上增加一個操作「判斷是否老年患者」，在原有「醫生介面」類上增加一個操作「提醒醫生有老年患者」。

【可能原因三】

醫院採購部門人員和廠家勾結，為了獲取回扣而購買劣質藥品和器械。

【改進方案】

3.1 改進採購流程。例如集中採購權，由採購辦主任把關審查。

圖12 改進方案3.1-採購辦主任把關

3.2 如果一定要「資訊化改進」，可以應用改進模式一「物流變為資訊流」，改為通過資訊系統傳遞採購申請，取消各部門採購人員的責任；應用改進模式三「封裝領域邏輯」，將採購辦主任大腦里的審查邏輯封裝一部分到HIS系統中，如圖13。

圖13 改進方案3.2-通過HIS系統傳遞資訊，由HIS系統封裝領域邏輯

從圖13可以看出，HIS系統多了兩個用例：

圖14 HIS系統多了兩個用例

要實現這兩個用例，可能的類圖如下：

圖15 HIS系統可能需要增加和修改的類

【可能原因四】

護士職業技能或職業素養存在問題，例如對患者宣講不到位，無菌操作不到位，沒有根據患者差異調節輸液速度等。

【改進方案】

4.1 加強培訓，加強監督，加大獎懲力度。例如，增加暗訪人員：

圖16 改進方案4.1-增加暗訪人員

4.2 如果一定要「資訊化改進」，可以把業務工人「暗訪員」替換成業務實體「監控系統」，事後安排監督員觀看錄像並評價。

圖17 改進方案4.2-引進監控系統代替暗訪人員

在市場上購買通用的監控系統應該可以滿足需求。

4.3 更進一步的資訊化改進，可以把護士這個業務工人去掉，用業務實體「超級輸液機」和「無人運葯小車」代替。

圖18 改進方案4.3-引進超級輸液機和無人運葯小車

從圖18可以映射出「超級輸液機」的用例：

圖19 超級輸液機的用例

可能的類圖如下：

圖20 超級輸液機的類圖

由上可見，針對一個「痛點」，可以有很多改進的可能。不同的可能中，是否需要引進資訊系統，引進新的資訊系統還是在原有資訊系統上改進，又有不同的選擇。不管是哪一種選擇，推導的思路是清晰的。

四、對問題域（Problem Domain）的誤用

圖21 摘自張逸文章《領域驅動戰略設計暨微服務設計工作坊》

當我們說起「功能」的時候，研究對象一般是系統。對於組織，一般說「組織的服務」，對於類，一般說「類的操作」。所以，「功能」屬於「需求」的範疇（所以有術語：功能需求），描述系統作為一個整體為其他系統提供的服務。

針對圖21，首先要說的是，功能不是What，是「做某事」。可以是「下單」（可能是系統用例級別），也可以是「計算運費」（步驟級別）。

按照張逸老師的觀點，問題域是功能，其他則屬於解決方案域。如果用我之前所舉案例的最後一種情況「超級輸液機」套上去，是不是應該如下圖？

圖22 按照張逸觀點劃分的「問題域」和「解決方案域」

說到「問題域」，估計2000年前後學習面向對象分析設計的開發人員會想到楊芙清、邵維忠寫的《面向對象的系統分析》（1998年，清華大學出版社）。當時，開發人員學習OOAD的資料並不多，這本書是當時很好的學習資料，書中說到「問題域」時，給出的都是如圖22下半部的類圖。當然，作者寫書的時候（不是出版的時候）UML標準還沒出現，書中用的是Peter Coad提倡的表示法。

《面向對象的系統分析》我手邊沒有，所以無法貼圖，不過楊邵跟隨的是Peter Coad和Edward Yourdon的思想，我們可以貼出Coad/Yourdon著作里的截圖：

圖23 摘自Coad, P., Yourdon, E., Object-Oriented Analysis, Second Edition. Yourdon Press, Inc. (1991)

從圖23可見，書中用於描述Problem Domain的是類和屬性。

順便把Coad/Yourdon著作里的「What」也貼一下：

圖24 摘自Coad, P., Yourdon, E., Object-Oriented Analysis, Second Edition. Yourdon Press, Inc. (1991)

可能有的讀者會覺得上面的貼圖說服力不大，因為書的名字就叫「Object-Oriented Analysis」，內容聚焦於分析工作流，你咋知道其他書里Problem Domain主要說的不是需求哩？

我們再來看軟體需求領域比較有名的著作，Karl Wiegers等所著的「Software Requirements」。書中很少提到 「Problem Domain」，正文第一次提到「Problem Domain」的截圖如下：

圖25 摘自Wiegers, K., Beatty, J., Software Requirements, Third Edition. Microsoft Press(2013)

圖25說的是數據字典，更接近於類的概念而不是系統功能的概念。

再看之前的ICONIX書，正文第一次提到「Problem Domain」的截圖如下：

圖26 摘自Rosenberg, D., Stephens, M., Use Case Driven Object Modeling with UML: Theory and Practice. Apress (2007)

同樣涉及整個開發過程而且比Rosenberg等人的書更流行的，應該是Craig Larman的書。我們也來看看Larman的書，正文第一次提到「Problem Domain」的截圖如下：

圖27 摘自Larman, C., Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Third Edition. Prentice Hall (2004)

最後來看Eric Evans的書。書中使用「Problem Domain」也比較少。正文第一次提到「Problem Domain」的截圖如下：

圖28 摘自Evans, E., Domain-Driven Design: Tackling Complexity in the Heart of Software Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley (2003)

圖28說的是非對象范型下的領域模型，說的還是系統內的核心機制-分析，而不是需求。

說了那麼多，我的觀點是：說系統功能屬於問題域是可以的，但不能說問題域指的就是系統功能，而把系統內部的核心域機制（例如分析類、分析狀態機）排除在問題域之外。

我更擔心的是，張逸老師可能犯了內外不分、需求和分析不分的錯誤。具體如何，沒有更進一步資訊不便猜測，大家可以看看我以下的文字有沒有參考價值。

我先說一下我對軟體建模工作流的劃分：

A-業務建模——描述所研究組織內部各系統（人腦系統、電腦系統……）如何協作，使得組織可以為其他組織提供服務。

B-需求——描述為了改進組織的問題，所研究系統必須具有的表現。

C-分析——提煉為了滿足功能需求，所研究系統需要封裝的核心域機制。

D-設計——為了滿足品質需求和設計約束，核心域機制如何映射到選定非核心域上實現。

為了兼容，以上四個工作流的名稱使用了傳統術語，也有一定的模糊性（特別是業務建模）。其實我覺得更貼切的名稱是組織建模、需求建模、核心域建模、實現。如果您覺得業務建模、需求、分析、設計不好，直呼ABCD或改成阿豬、阿狗、阿雞、阿鴨也無所謂。關鍵是要了解劃分的依據：一個是研究範圍，一個是研究內容。如圖29：

圖29 不同工作流的研究範圍和內容

再說一下核心域和非核心域的概念。一個軟體系統封裝了若干領域的知識，其中一個領域的知識代表了系統的核心競爭力，是系統和其他系統區分的關鍵所在。這個領域稱為"核心域"，其他領域稱為"非核心域"。更通俗的說法是"業務"和"技術"，但使用"核心域"和"非核心域"更嚴謹。核心域不一定是物流、醫療、金融等非電腦領域，也可以是電腦和軟體領域。

問題域就是這裡說的核心域。

圖30展示了不同系統的核心域和非核心域概念：

圖30 不同系統的核心域、非核心域概念

在軟體開發中，業務建模和需求工作流致力於解決「系統好賣」的問題，分析和設計工作流致力於解決「降低開發成本」的問題。二者不能也不應直接映射。

以常見的「系統」人體舉例。人體的基本功能有走路、跳躍、吃飯等，但是思考人體內部結構時，不能從外部直接映射到內部，得到人體由「走路模組」、「跳躍模組」、「吃飯模組」組成，這樣會導致大量的冗餘。人體的「模組」是五官四肢和內臟，還有最關鍵的——「大腦」。不管是走路、跳躍還是吃飯或者將來發展出更多的「功能」，都應該儘可能復用這些已有的「模組」來協作完成。

還是以「超級輸液機」為例。如果從需求直接映射到分析設計，會得到很多無價值的類，如下圖：

圖31 假面向對象抽象

沒有基本的面向對象抽象思維的開發人員，即使使用面向對象的程式語言來編碼，也只是直接把系統的某個功能加上or或er作為類名稱，然後在這個××or或××er類的操作里寫面向過程的程式碼。這樣做表面上似乎是面向對象了，實際上是換湯不換藥，沒有得到面向對象的好處。想想也是理所當然的，根本沒有付出思考，問題怎麼會自己消失？

如果從分析設計出發來定義需求，會得到一堆假的「需求」，典型的就是「××管理」。就以張逸老師文章里的一張圖為例：

圖32 摘自張逸文章《領域驅動戰略設計暨微服務設計工作坊》

這些「××管理」怎麼來的？希望不是自內而外得來——先設想以後資料庫里有客戶表，所以推導出系統有用例「客戶管理」……。

系統的需求應該從外面，即組織的流程來映射，可參見本文前面提供的業務序列圖。

再說一個現實生活的類比，希望對理解前面的內容有幫助。

麵館廚師擅長用若干種原料（組件）靈活組合出許多吃法（用例）賣給不同的顧客。同樣是以麵粉、肉、菜、蛋為主原料，麵館可以提供饅頭、包子、花捲、燒餅、餃子、餛飩、鍋貼、燒麥、春卷、油條、發糕……拉麵、刀削麵、擀麵、擦面、哨子面、扯麵、油潑面、擔擔麵、拌面、燜面、麵疙瘩、揪面片、手擀麵、拉條子、炒麵……臊子面、沙茶麵、茄丁面、酸菜面、雞蛋面、蝦仁面、牛肉麵……

我去麵館就餐，點了一碗餛飩，過了一會，老闆端來一碗餃子。我說，「老闆，這是餃子，不是餛飩！」老闆肯定不能嘲笑我，「笨，餃子和餛飩98%是一樣的，都是麵粉和肉菜的組合，製作製程也差不多，你就將就著吃吧！」。要是這樣我會扭頭就走，因為隔壁還有麵館（這個最關鍵！）。

老闆可以把餃子端回後廚，經過快速分解，重新組合，幾分鐘之後餃子變成了餛飩，然後又端出來給我。我並不了解餛飩哪裡來的，只要味道比隔壁的好，價格又公道，我就吃唄。

當然，絕大多數的麵館沒有把已經煮好的餃子分解再組合快速變餛飩的黑科技，多半是用新的原料重新快速做一份餛飩。

但軟體開發的原料複製起來並不需要錢啊！

未完待續……

接下來的論題：

五、需求、分析……是階段嗎

……

再重複開頭的內容：