本文圍繞業(yè)務(wù)，從涉及問題范圍、開發(fā)挑戰(zhàn)、建模三方面入手，結(jié)合實際案例，展開了詳細(xì)的分析。希望對你有幫助。

一、業(yè)務(wù)問題

1、關(guān)于業(yè)務(wù)

業(yè)務(wù)（Business）：

在大多數(shù)情況下，表示一個組織、公司或個人所從事的商業(yè)活動、服務(wù)或工作，有相應(yīng)的流程和規(guī)則?？梢岳斫鉃檫_(dá)成某種目的（如盈利、增長、滿足客戶需求等）所進(jìn)行的各種活動，涉及到如何創(chuàng)建價值、滿足需求和實現(xiàn)目標(biāo)。

業(yè)務(wù)相關(guān)活動所涉及的問題范圍，即問題域（Business Domain），問題域通常也就是公司為其客戶提供的服務(wù)。以支付業(yè)務(wù)為例：

• 支付，是一種經(jīng)濟(jì)活動，有經(jīng)濟(jì)活動就有支付需求。其業(yè)務(wù)流程覆蓋交易，清算和結(jié)算過程（即互動行為，信息流動以及資金流動）。
• 支付，是金融體系最重要和最基礎(chǔ)的功能，涉及到行為眾多參與方的共同活動，因此又關(guān)系到相關(guān)的行業(yè)標(biāo)準(zhǔn)/規(guī)范和法律法規(guī)。

支付業(yè)務(wù)從等價物交換，到貨幣支付，再進(jìn)入電子支付，從單純銀行卡收單走向第三方支付平臺。而第三方支付所研究的問題從起初的面向商業(yè)場景的收單，走向面向用戶的電子錢包到面向企業(yè)及行業(yè)的資金運用效率的問題。

如果說央行支付清算體系是社會經(jīng)濟(jì)的大動脈，那么第三方支付就是連通全社會的分支血管和毛細(xì)血管。

2、關(guān)于產(chǎn)品

產(chǎn)品，通常是指對應(yīng)的業(yè)務(wù)背景下為相關(guān)問題域提供的解決方案，即為用戶/目標(biāo)組織所提供的系統(tǒng)或服務(wù)。

針對支付業(yè)務(wù)，市場上面向用戶提供了各種類型的產(chǎn)品，如面向線下收單的各類解決方案，到現(xiàn)在的第三方支付平臺“微信支付”、“支付寶”上面向業(yè)務(wù)訴求和場景所提供支付產(chǎn)品。從業(yè)務(wù)問題域側(cè)重點的差異可以看到產(chǎn)品形態(tài)的差異。

• 微信支付：為個人和企業(yè)提供在線支付服務(wù)，產(chǎn)品有支付產(chǎn)品（付款碼支付、小程序支付…）。
• 支付寶：相關(guān)產(chǎn)品（App支付，當(dāng)面付…）、營銷產(chǎn)品（商家券…），資金產(chǎn)品（花唄分期..）

支付產(chǎn)品服務(wù)的用戶和目標(biāo)組織，包含支付網(wǎng)絡(luò)中連接到的個人、企業(yè)、商家和其他組織機構(gòu)。

比如，線下或線上的各類商家、各行業(yè)的服務(wù)提供商、甚至政府機構(gòu)，也比如小商戶，或需要收付款的任何個體等。他們因在支付服務(wù)中獲得價值而使用并提出各類需求。

3、關(guān)于系統(tǒng)

產(chǎn)品是對解決方案的包裝，支撐起解決方案的實現(xiàn)即系統(tǒng)（業(yè)務(wù)系統(tǒng)）。如：

• 銀聯(lián)業(yè)務(wù)背后的CUPS系統(tǒng)(China UnionPay System)
• 微信支付背后的微信支付系統(tǒng)(WeChat Pay System)

公司向市場提供的每種產(chǎn)品都是執(zhí)行各類活動的結(jié)果。而信息系統(tǒng)在業(yè)務(wù)流程管理中應(yīng)發(fā)揮重要作用，因為公司執(zhí)行的越來越多的活動都得到信息系統(tǒng)的支持。業(yè)務(wù)流程中的活動可以由公司員工手動或借助信息系統(tǒng)來執(zhí)行。

還有一些業(yè)務(wù)流程活動可以由信息系統(tǒng)自動執(zhí)行，無需任何人工參與。只有人與其他企業(yè)資源（例如信息系統(tǒng)）良好地協(xié)同工作，企業(yè)或組織才能高效、有效地實現(xiàn)其業(yè)務(wù)目標(biāo)。

業(yè)務(wù)流程是促進(jìn)這種有效協(xié)作的重要概念。在非科技行業(yè)的各類公司中，組織的業(yè)務(wù)方面與現(xiàn)有信息技術(shù)之間存在差距?？s小組織和技術(shù)之間的差距非常重要，因為在當(dāng)今充滿活力和競爭的市場中，公司必須得向客戶提供更好的產(chǎn)品/服務(wù)才能生存。

而信息系統(tǒng)讓公司和組織，甚至行業(yè)得以大幅提效。這里的信息系統(tǒng)，即面向業(yè)務(wù)改進(jìn)所建設(shè)的軟件系統(tǒng)，即業(yè)務(wù)開發(fā)所交付的“業(yè)務(wù)系統(tǒng)”。

再以支付為例，其業(yè)務(wù)邊界和業(yè)務(wù)形態(tài)的演變，得力于信息系統(tǒng)逐步對業(yè)務(wù)流程不斷改進(jìn)（如信息流/資金流）。

做交互设计10年，我为何转岗到产品经理？

真正转岗之后，我发现很多工作还是超出了自己的想象。产品经理的工作确实比较杂。理论上，产品经理的工作包括了产品的方方面面，从市场研究、用户调研、数据分析...

查看详情 >

其所形成的支付系統(tǒng)的形成過程，正是通過對支付業(yè)務(wù)的問題域不斷研究的結(jié)果，通過流程改造、自動化和信息化替代人工流程，將支付解決方案不斷提效、拓展、升級的過程。

二、開發(fā)挑戰(zhàn)

業(yè)務(wù)就是為客戶提供價值以獲取利潤。經(jīng)營企業(yè)就是有能力預(yù)判并做出決策，而信息是決策質(zhì)量最重要的決定因素。信息系統(tǒng)的設(shè)計必須確保所提供的信息及時、準(zhǔn)確且充分相關(guān)。

只有當(dāng)我們了解做出這些決策的背景時，我們才能確保信息系統(tǒng)以這種方式支持業(yè)務(wù)決策。業(yè)務(wù)開發(fā)，冠以“業(yè)務(wù)”前綴，要的是在技術(shù)通識的基礎(chǔ)上，更要熟悉業(yè)務(wù)。是另一個維度的全棧（業(yè)務(wù)+技術(shù)）能力。業(yè)務(wù)開發(fā)團(tuán)隊，要承接并交付出“好”的業(yè)務(wù)系統(tǒng)，挑戰(zhàn)在兩點：

1. 從0到1階段：洞察用戶痛點，解決核心用戶問題
2. 1到100階段：業(yè)務(wù)系統(tǒng)能輕松的高質(zhì)量的動態(tài)進(jìn)化,在不斷發(fā)展中支持業(yè)務(wù)攻城略地

這也是大多數(shù)團(tuán)隊所面臨的挑戰(zhàn)：

洞察痛點：本質(zhì)在于理解業(yè)務(wù)，能夠定義邊界/聚焦重點

• 【面向需求】要開發(fā)什么樣的產(chǎn)品？
• 【面向業(yè)務(wù)】為什么要開發(fā)這個產(chǎn)品？要解決什么問題，達(dá)成什么目標(biāo)？

動態(tài)進(jìn)化：本質(zhì)依托于業(yè)務(wù)系統(tǒng)的設(shè)計和實現(xiàn)

• 【面向設(shè)計】如何做才能契合業(yè)務(wù)形態(tài)應(yīng)對變化、減少制約以更好地達(dá)成目標(biāo)？

以微信支付的紅包產(chǎn)品為例：

• 回顧需求：將線下紅包收發(fā)場景線上化，有普通紅包，群紅包，搖紅包…
• 背后業(yè)務(wù)：紅包業(yè)務(wù)：賬戶/資金流/業(yè)務(wù)流程…業(yè)務(wù)目標(biāo)：拉新，綁卡，入金，活躍，…
• 設(shè)計實現(xiàn)：要對接用戶/商戶/金融機構(gòu)，高效準(zhǔn)確的處理資金的收付退；面向節(jié)假日高峰，系統(tǒng)架構(gòu)如何定義和應(yīng)對…

業(yè)務(wù)上“知其然知其所以然”，將有能力優(yōu)化業(yè)務(wù)流程，準(zhǔn)確評估需求甚至發(fā)現(xiàn)需求，甚至建立預(yù)判能力，為業(yè)務(wù)系統(tǒng)構(gòu)建靈活運營能力，更好的提升產(chǎn)品市場地位。業(yè)務(wù)開發(fā)的挑戰(zhàn)，這里探討兩點：1-理解業(yè)務(wù)，2-融入業(yè)務(wù)視角來設(shè)計/構(gòu)建系統(tǒng)。

注：本篇先探討第一部分。第二部分在下一篇繼續(xù)。

1、理解業(yè)務(wù)

理解業(yè)務(wù)，需要以全面透徹的視角看業(yè)務(wù)，了解涉眾訴求、利益關(guān)系以及價值鏈。作為業(yè)務(wù)開發(fā)，讀/寫代碼、轉(zhuǎn)換用戶視角使用產(chǎn)品功能外，要從行業(yè)發(fā)展過程和法規(guī)管控原因去理解業(yè)務(wù)。對于技術(shù)要承載的業(yè)務(wù)，要跳出單一代碼視角，從兩種視角拆開看：

• 問題空間（Problem）：即業(yè)務(wù)的問題域，探討和關(guān)注的是有什么問題要解決，或者存在什么痛點要消除，也即需求；
• 解空間（Solution）：也稱解決方案域，考慮有哪些方案去解決這些問題；最終用哪個方案做到了，稱為實現(xiàn)。

區(qū)分這兩部分的意義在于：提問題比解決問題更重要。提對問題，才能找對方向，給出多種方案，才能控制風(fēng)險防止南轅北轍。

在工作過程中，需要將兩方面分開討論，而不是混淆在一起。這能幫助我們把注意力放到要聚焦的問題本身，去關(guān)注用戶想要什么（Want）、痛在哪里，再去列舉可能的解決方案（How）。

反之，輕則只理解表面上的交互流程，導(dǎo)致面向UI開發(fā) （例如，將領(lǐng)域邏輯和業(yè)務(wù)規(guī)則直接寫到UI層或者寫成Transaction Script，導(dǎo)致實則是應(yīng)該被領(lǐng)域?qū)ο蠊芸氐臉I(yè)務(wù)規(guī)則被分散到各處而失去維護(hù)性）；重則方向性錯誤，前功盡棄。

動手之前，通過面向業(yè)務(wù)提好的問題，能幫助我們發(fā)現(xiàn)業(yè)務(wù)本質(zhì)、覆蓋全局且不留死角。初識業(yè)務(wù)，或者成熟業(yè)務(wù)上擴(kuò)展出新需求，需要主動思考：

• 這個業(yè)務(wù)，現(xiàn)狀是什么樣的，為誰服務(wù)？
• 這個業(yè)務(wù)，全景是怎樣的？上下游、合作方涉及哪些內(nèi)容？他們是怎么合作的？
• 這個業(yè)務(wù)，最核心的價值在哪里？利潤從何而來？
• 這個業(yè)務(wù)，最重要的待解決的問題是什么？
• 這個業(yè)務(wù)，當(dāng)前市面上有哪些解決方案，這些產(chǎn)品是以什么思路設(shè)計的？
• …

在探討上述問題之后，還可進(jìn)一步應(yīng)用熟悉業(yè)務(wù)，比如：

2、做對需求

需求不僅僅是TAPD上的表面的交互或說明，其本質(zhì)是要基于業(yè)務(wù)背景為用戶創(chuàng)造價值。功能需求是用戶價值點，而非功能需求則為產(chǎn)品放大競爭力（對應(yīng)的質(zhì)量屬性，如用戶體驗、性能、兼容性，安全性等）。

對于純互聯(lián)網(wǎng)C端產(chǎn)品，多以工具型產(chǎn)品為主，本身構(gòu)建于數(shù)字化基礎(chǔ)體系之上，且問題域的涉眾相對角色少（開發(fā)者自身就是核心用戶）。

其需求更多以點狀出現(xiàn)，然后通過MVP和原型化的方法在過程中進(jìn)行快速試錯進(jìn)行驗證和提煉，這樣的需求多會以交互/用戶故事輕量化的管理和呈現(xiàn)。

但在B端或面向行業(yè)，其業(yè)務(wù)流程長且內(nèi)稟邏輯復(fù)雜，業(yè)務(wù)場景下參與的角色眾多，而且領(lǐng)域?qū)＜液徒鉀Q方案團(tuán)隊大多并未重合，開發(fā)者需要跨領(lǐng)域?qū)W習(xí)業(yè)務(wù)知識，比如金融/證券/保險的業(yè)務(wù)，又或者是零售/消費電子制造等行業(yè)都有自身行話術(shù)語，以及產(chǎn)品內(nèi)的特定業(yè)務(wù)流程和業(yè)務(wù)規(guī)則。

這種場景下，對于業(yè)務(wù)系統(tǒng)的建設(shè)團(tuán)隊的挑戰(zhàn)有：

• 需求背后涉及的業(yè)務(wù)，其目標(biāo)組織是如何運作和分工協(xié)作以執(zhí)行業(yè)務(wù)活動的
• 如何讓團(tuán)隊成員準(zhǔn)確理解和評估最終用戶的需求，和目標(biāo)組織就業(yè)務(wù)系統(tǒng)的價值達(dá)成共識
• 如何讓大型團(tuán)隊協(xié)作的成員之間的理解一致，以防止出現(xiàn)實現(xiàn)不一致
• 如何業(yè)務(wù)知識如何有效沉淀和迭代，而不因團(tuán)隊變化導(dǎo)致信息缺失
• 如何為業(yè)務(wù)建設(shè)出匹配的可長期運營的業(yè)務(wù)系統(tǒng)，而不在演進(jìn)過程中發(fā)現(xiàn)重大缺陷……

相信大型、跨多團(tuán)隊協(xié)作建設(shè)和運營的長生命周期業(yè)務(wù)系統(tǒng)會有同感。對于支付業(yè)務(wù)，在為不同行業(yè)的企業(yè)/商家提供有競爭力的在支付/資金解決方案過程中，更感受到透過產(chǎn)品表面形態(tài)穿透業(yè)務(wù)本身的意義和價值。

此處的不斷實踐，我們將上述挑戰(zhàn)的解決方案落腳于業(yè)務(wù)建模方法上。來一起看看：業(yè)務(wù)建模。

三、業(yè)務(wù)建模

1、模型（Model）

幾乎所有的創(chuàng)作者都會用模型來表達(dá)。當(dāng)我們想要建造汽車橋梁和建筑物時，我們會先制作模型。當(dāng)我們想要制作和定義電氣設(shè)備時，我們會繪制電路圖。我們用公式來理解物理、化學(xué)和數(shù)學(xué)。

幾乎在每一個學(xué)科中，我們很自然的使用模型的表達(dá)方式來澄清我們在做什么。模型為我們闡明了某事物或某事件的某些方面或某些觀點。為了實現(xiàn)這樣的通用目的，模型主要分為靜態(tài)和動態(tài)兩種：靜態(tài)模型呈現(xiàn)結(jié)構(gòu)，動態(tài)模型呈現(xiàn)事件流。

2、建模（Modeling）

是一種處理復(fù)雜性的手段。建模意味著構(gòu)建一個系統(tǒng)的抽象，通過抽象模型關(guān)注感興趣的方面并忽略不相關(guān)的細(xì)節(jié)。

建模使我們能夠通過分而治之的方法處理復(fù)雜性：對于我們想要解決的每種類型的問題，我們構(gòu)建一個僅關(guān)注與問題相關(guān)的問題的模型。一般來說，建模的重點是建立一個足夠簡單、可以讓人完全掌握的模型。

廣義的業(yè)務(wù)模型（Business Model），用以明確目標(biāo)組織（公司/組織）的功能，顯示其所處的環(huán)境以及在環(huán)境中的行為方式。此處的環(huán)境是公司為執(zhí)行其業(yè)務(wù)流程與之交互的所有事物，如客戶、合作伙伴、供應(yīng)商等。業(yè)務(wù)模型能用于系統(tǒng)的管理公司的發(fā)展，幫助降低風(fēng)險增加成功概率。

如：組織架構(gòu)定義、業(yè)務(wù)活動的參與角色和執(zhí)行流程等。這里打住，回到我們的業(yè)務(wù)開發(fā)語境下的業(yè)務(wù)建模，是面向業(yè)務(wù)交付信息系統(tǒng)的目標(biāo)下所探討的內(nèi)容。

因此，我們探討的業(yè)務(wù)建模（Business Modeling）是指通過對目標(biāo)用戶/組織的業(yè)務(wù)需求、流程和規(guī)則進(jìn)行分析和描述，并以抽象模型呈現(xiàn)出來，從而為軟件系統(tǒng)的需求、分析、設(shè)計和實現(xiàn)提供基礎(chǔ)的過程。

業(yè)務(wù)建模能幫助項目團(tuán)隊更好地理解用戶的業(yè)務(wù)背景，發(fā)現(xiàn)用戶可改進(jìn)點，確保軟件系統(tǒng)與實際業(yè)務(wù)需求保持一致，更好的提高用戶滿意度。

此外，業(yè)務(wù)建模還有助于提高項目團(tuán)隊和客戶之間的溝通效率，降低項目風(fēng)險。業(yè)務(wù)建模通常會通過創(chuàng)建一系列模型（如業(yè)務(wù)用例模型、業(yè)務(wù)分析模型等）來表示和組織這些業(yè)務(wù)需求、流程和規(guī)則的過程。

3、業(yè)務(wù)建模的目標(biāo)

• 了解目標(biāo)組織的結(jié)構(gòu)及運行機制
• 了解目標(biāo)組織中當(dāng)前存在的問題并找出改進(jìn)的潛力（放大價值?。?/li>
• 評估組織變革帶來的影響
• 確?？蛻?、最終用戶和開發(fā)人員就目標(biāo)組織達(dá)成共識
• 導(dǎo)出支持目標(biāo)組織所需的軟件系統(tǒng)需求
• 理解將交付的軟件系統(tǒng)如何在目標(biāo)組織中工作

業(yè)務(wù)建模描述了如何評估當(dāng)前組織并制定新組織的愿景。然后，以該愿景為基礎(chǔ)，在業(yè)務(wù)用例模型和業(yè)務(wù)分析模型中定義該組織的流程、角色和職責(zé)。

可見，業(yè)務(wù)建模很好的應(yīng)對了我們在做需求時所提到的挑戰(zhàn)：理解業(yè)務(wù)，做對需求甚至洞察需求。

4、業(yè)務(wù)建模的技術(shù)

業(yè)務(wù)建模是一種技術(shù)，建模語言常見的有UML和BPMN等，基于通識我們主要使用了UML。業(yè)務(wù)建模的UML常用符號如下：

在我們的實踐中，多采用序列圖來梳理業(yè)務(wù)流程（實例中的圖示感覺很好理解，對吧）。相關(guān)業(yè)務(wù)建模的符號說明如下：

5、業(yè)務(wù)建模的輸出物

要達(dá)成上述目標(biāo)，業(yè)務(wù)建模方法描述了如何評估當(dāng)前組織并確定組織愿景，并以愿景為基礎(chǔ)，在【業(yè)務(wù)用例模型】和【業(yè)務(wù)分析模型】中定義組織的流程、角色和職責(zé)。

因為僅靠目標(biāo)組織的結(jié)構(gòu)圖不足以了解其運作方式。我們還需要業(yè)務(wù)的動態(tài)視圖。業(yè)務(wù)模型提供組織結(jié)構(gòu)的靜態(tài)視圖和組織內(nèi)流程的動態(tài)視圖。

模型類型及其關(guān)系

• 理解業(yè)務(wù)，得出業(yè)務(wù)用例模型和業(yè)務(wù)分析模型
• 從而推導(dǎo)出指導(dǎo)系統(tǒng)開發(fā)的“用例模型、分析模型、設(shè)計模型和實現(xiàn)模型”
• 業(yè)務(wù)建模指導(dǎo)系統(tǒng)開發(fā)
• 業(yè)務(wù)建模階段輸出業(yè)務(wù)用例模型和業(yè)務(wù)對象模型

業(yè)務(wù)用例模型（Business Use case Model）

• 業(yè)務(wù)執(zhí)行者（Business Actor）：代表業(yè)務(wù)環(huán)境中某人或某物所扮演的與業(yè)務(wù)相關(guān)的角色。如用戶、供應(yīng)商或合作伙伴等。
• 業(yè)務(wù)用例（Business Use case）：業(yè)務(wù)執(zhí)行者希望通過和組織交互獲得的由組織提供的價值。業(yè)務(wù)用例必須支持業(yè)務(wù)目標(biāo)。目標(biāo)領(lǐng)域中的業(yè)務(wù)流程，由業(yè)務(wù)用例和其實現(xiàn)來表示。建模業(yè)務(wù)用例和參與者的目的是描述客戶和關(guān)聯(lián)方如何做業(yè)務(wù)。呈現(xiàn)直接涉及客戶或關(guān)聯(lián)方的活動，以及間接涉及外部各方的支持或管理任務(wù)。
• 業(yè)務(wù)所需功能的模型，用作識別目標(biāo)組織中的角色和對外交付的價值（可交付件）

業(yè)務(wù)分析模型（Business Analysis Model，也稱業(yè)務(wù)對象模型）

• 業(yè)務(wù)的分析模型描述了通過業(yè)務(wù)工人和業(yè)務(wù)實體交互來實現(xiàn)業(yè)務(wù)用例。
• 抽象了業(yè)務(wù)工人和業(yè)務(wù)實體需要如何關(guān)聯(lián)及如何協(xié)作才能執(zhí)行業(yè)務(wù)用例。
• 業(yè)務(wù)工人（Business Worker）：組織內(nèi)部的人員所承擔(dān)的角色
• 業(yè)務(wù)實體（Business Entity）：組織所管理或產(chǎn)生的事物
• 描述業(yè)務(wù)用例執(zhí)行的對象模型，不對業(yè)務(wù)用例如何實現(xiàn)做假設(shè)

其次，也需要以下輸出做為補充：

• 業(yè)務(wù)愿景（Business Vision）：建設(shè)系統(tǒng)的目的是什么，如何量化
• 業(yè)務(wù)規(guī)則（Business Rules）：必須遵守的政策或條件的聲明
• 業(yè)務(wù)術(shù)語表（Business Glossary）：定義在項目的業(yè)務(wù)建模部分所使用的重要術(shù)語
• 有必要也可以補充業(yè)務(wù)架構(gòu)文檔和相關(guān)業(yè)務(wù)規(guī)范

參考RUP過程示例模型：

上圖中，通過業(yè)務(wù)用例和業(yè)務(wù)流程，識別業(yè)務(wù)執(zhí)行者和業(yè)務(wù)實體（注：Business Object Model應(yīng)用了ECB模式， 一種承載業(yè)務(wù)執(zhí)行者和業(yè)務(wù)工人以及實體之間的活動圖，Iconix方法稱之為robustness analysis），并提煉出系統(tǒng)用例和分析模型。建模、理解和改進(jìn)業(yè)務(wù)非常類似于構(gòu)建軟件系統(tǒng)。

可以看成一次探索的過程，其中包括確定目標(biāo)和范圍，通過高維框架逐步細(xì)化，通過整體視角，細(xì)節(jié)部分去不斷審視，基于新的理解和洞察來更新模型，基本也是迭代完善的過程。

6、業(yè)務(wù)建模實例

說了很多，通過推演一個餐廳的小例子來熟悉下業(yè)務(wù)建模流程和效果。業(yè)務(wù)建模通過UML可視化業(yè)務(wù)流程，實踐中我們通過用例圖和序列圖和輸出業(yè)務(wù)模型。下面通過餐飲行業(yè)一個小例子來探討業(yè)務(wù)建模過程。

1、目標(biāo)組織：餐飲行業(yè)類商戶

• 核心涉眾：飯店老板
• 組織結(jié)構(gòu)：較簡單，可以試想想，用靜態(tài)結(jié)構(gòu)呈現(xiàn)，了解各部分功能

2、組織的業(yè)務(wù)

為消費者（即顧客）提供餐飲；

3、業(yè)務(wù)建模的目標(biāo)

• 改進(jìn)業(yè)務(wù)流程，提高服務(wù)效率和質(zhì)量（接待/上菜速度）
• 業(yè)務(wù)用例：組織提供了哪些價值

4、業(yè)務(wù)用例：組織提供了哪些價值

5、業(yè)務(wù)現(xiàn)狀：當(dāng)前的業(yè)務(wù)活動及執(zhí)行流程

某飯店現(xiàn)有堂食的業(yè)務(wù)流程如上，涉及多位業(yè)務(wù)工人（領(lǐng)位/服務(wù)/收銀）及業(yè)務(wù)實體（綠色部分）；消費者消費時，需要與各類業(yè)務(wù)工人交互，涉及紙質(zhì)記錄、現(xiàn)金等，存在易出錯效率低成本高等各類問題。

（注：RUP/軟件方法的建模方法在這一點上有規(guī)范上的差異見附錄1）

6、業(yè)務(wù)改進(jìn)：建模改進(jìn)，通過業(yè)務(wù)系統(tǒng)實現(xiàn)自動化改進(jìn)業(yè)務(wù)流程

改進(jìn)后的業(yè)務(wù)流程，創(chuàng)新的通過餐廳運營系統(tǒng)，以自動化的方式消除了多個業(yè)務(wù)工人，隱藏了多個業(yè)務(wù)實體。人工處理流程更簡單，大幅提高效率和各方體驗，由于通過飯店賬號與消費者建立了聯(lián)系，還可以主動營銷提升回購率。接入微信支付系統(tǒng)則大幅提升可用的用戶付款方式。

7、確認(rèn)業(yè)務(wù)系統(tǒng)的需求：從通過改進(jìn)的業(yè)務(wù)序列圖，確認(rèn)餐廳運營系統(tǒng)對外提供的價值。這些價值即系統(tǒng)要對外提供的能力，如預(yù)訂、查閱菜單等。系統(tǒng)用例如圖：

8、確認(rèn)系統(tǒng)需求，進(jìn)入系統(tǒng)分析和設(shè)計階段。

如上一個入門級的業(yè)務(wù)建模過程，當(dāng)然還有更多進(jìn)一步的完善流程這里不做細(xì)致描述。但我們可以看到，通過模型即可快速進(jìn)行業(yè)務(wù)流程的確認(rèn)和分析，甚至對原有業(yè)務(wù)流程進(jìn)行改進(jìn)，找出建設(shè)系統(tǒng)的需求并為進(jìn)一步提升組織的業(yè)務(wù)競爭力打下基礎(chǔ)。

這樣的改進(jìn)場景很多，使用自動化的系統(tǒng)代替人工實現(xiàn)降本增效最終提升競爭力，如掃碼點餐，滴滴打車等。針對業(yè)務(wù)建模方法，下面的梳理提煉方便大家有個整體輪廓。

注意【業(yè)務(wù)】二字，表示不帶入任何實現(xiàn)，僅關(guān)注業(yè)務(wù)（如業(yè)務(wù)用例…業(yè)務(wù)分析…）。

7、業(yè)務(wù)建模的工作流

以經(jīng)典的RUP過程為例，基本的業(yè)務(wù)建模的工作流如下圖（注意，與《軟件方法》有區(qū)別：

我們可以選擇工作流的多種路徑之一，選擇的路徑取決于的業(yè)務(wù)建模工作的目的以及開發(fā)階段。

在第一次迭代時，需要評估組織狀態(tài)并確定建模目標(biāo)。再決定如何迭代。

• 描述業(yè)務(wù)現(xiàn)狀
• 識別和改進(jìn)業(yè)務(wù)流程
• 研究流程自動化（建立系統(tǒng)）

如果不需要對整體業(yè)務(wù)進(jìn)行建模，只關(guān)注領(lǐng)域模型，則走領(lǐng)域建模過程。

另外，當(dāng)業(yè)務(wù)不做變更，可以通過業(yè)務(wù)建模分析的內(nèi)容導(dǎo)出軟件需求。

上述核心路徑描述如下：

一、業(yè)務(wù)建模（Business Modeling）

1. 描述業(yè)務(wù)現(xiàn)狀：輸出業(yè)務(wù)現(xiàn)狀的業(yè)務(wù)用例模型、業(yè)務(wù)分析模型

① 評估目標(biāo)組織，識別業(yè)務(wù)目標(biāo)（Goal）

組織結(jié)構(gòu)：組織的靜態(tài)結(jié)構(gòu)與職責(zé)分工；

確認(rèn)業(yè)務(wù)目標(biāo)：定義了要達(dá)成可持續(xù)競爭地位必須做到什么，可以按組織結(jié)構(gòu)分解。

② 了解組織當(dāng)前的流程和結(jié)構(gòu)

找出業(yè)務(wù)執(zhí)行者：從與業(yè)務(wù)交互的任何個人、團(tuán)隊、組織，公司中找；

找出業(yè)務(wù)用例：從業(yè)務(wù)執(zhí)行者從業(yè)務(wù)中獲得的價值來找；

找出業(yè)務(wù)工人：組織內(nèi)的角色（人或系統(tǒng)），其履行相應(yīng)的角色；

找出業(yè)務(wù)實體：組織內(nèi)業(yè)務(wù)工人處理的重要且持久的信息；

收集公共業(yè)務(wù)名詞：項目早期就通用業(yè)務(wù)術(shù)語達(dá)成一致非常重要；

制定業(yè)務(wù)規(guī)則：規(guī)則的來源有些是法規(guī)強加，有些是業(yè)務(wù)執(zhí)行的標(biāo)準(zhǔn)。

③細(xì)化業(yè)務(wù)建模的目標(biāo)

界定業(yè)務(wù)建模工作：面向整個組織，還是業(yè)務(wù)流程的子集；

制定組織愿景，識別涉眾：要解決什么問題，交付的業(yè)務(wù)系統(tǒng)涉及哪些相關(guān)方；

確定業(yè)務(wù)建模目標(biāo)：涉及不同的范圍，包括：確認(rèn)組織結(jié)構(gòu)，輸出領(lǐng)域模型，為業(yè)務(wù)構(gòu)建系統(tǒng)，建立通用業(yè)務(wù)模型，構(gòu)建新業(yè)務(wù)，業(yè)務(wù)改造。選擇其中一種。

2. 找出業(yè)務(wù)改進(jìn)：以現(xiàn)狀的業(yè)務(wù)模型為起點對業(yè)務(wù)流程改進(jìn)或重新思考

①識別業(yè)務(wù)流程及優(yōu)先級

明確術(shù)語、確定支持業(yè)務(wù)戰(zhàn)略的業(yè)務(wù)目標(biāo)；

輸出業(yè)務(wù)用例模型；

確定各業(yè)務(wù)用例的優(yōu)先級：尋找支持最重要業(yè)務(wù)目標(biāo)的業(yè)務(wù)用例。

②完善業(yè)務(wù)流程定義：詳細(xì)說明業(yè)務(wù)流程并描述其如何支持業(yè)務(wù)目標(biāo)

③設(shè)計業(yè)務(wù)流程實現(xiàn)：描述如何在業(yè)務(wù)對象模型中根據(jù)協(xié)作對象（業(yè)務(wù)工人和業(yè)務(wù)實體的實例）實現(xiàn)特定業(yè)務(wù)用例

④細(xì)化角色和職責(zé)：詳細(xì)說明業(yè)務(wù)實體、業(yè)務(wù)工人和業(yè)務(wù)事件，并驗證業(yè)務(wù)建模的結(jié)果是否符合涉眾的業(yè)務(wù)視角

3. 研究流程的自動化：確認(rèn)流程中哪些部分可以并應(yīng)該自動化

①三類自動化方式

縮短用例交付時間：提高現(xiàn)有工作方式的效率，但工作方式?jīng)]變；

重新組織或排序業(yè)務(wù)流程的活動：對業(yè)務(wù)用例做創(chuàng)新型改進(jìn)，改變現(xiàn)有工作方式；

監(jiān)視、控制和改進(jìn)工作方式。

②理解如何讓軟件系統(tǒng)滿足組織需求

③定義自動化需求：導(dǎo)出目標(biāo)要建設(shè)的軟件系統(tǒng)的軟件需求

二、領(lǐng)域建模（Domain Modeling）：

識別業(yè)務(wù)領(lǐng)域中的概念，提供對業(yè)務(wù)運營和環(huán)境中的概念的共同一致的理解。

識別業(yè)務(wù)領(lǐng)域中的所有產(chǎn)出和可交付成果。

上述的簡要流程每一步都有具體的定義，涉及內(nèi)容很廣，這里不做詳細(xì)描述?？偠灾?，業(yè)務(wù)建?？梢蕴釤挒橐韵聨撞剑哼x定組織，了解業(yè)務(wù)，描述業(yè)務(wù)現(xiàn)狀，改進(jìn)業(yè)務(wù)；這里需要的是讓組織提供的價值更大。

上面看到業(yè)務(wù)建模輸出的模型有兩種：業(yè)務(wù)用例模型與業(yè)務(wù)分析模型（業(yè)務(wù)對象模型）。而上述的領(lǐng)域建模是業(yè)務(wù)建模中的“描述業(yè)務(wù)現(xiàn)狀”的精簡版，只識別“業(yè)務(wù)實體”。

（注意，此處的“領(lǐng)域模型”是業(yè)務(wù)級別的分析模型，非業(yè)務(wù)流程，也非DDD的領(lǐng)域模型）

另外要注意的是，需要讓每個業(yè)務(wù)實體及使用到的任何業(yè)務(wù)術(shù)語都定義到業(yè)務(wù)術(shù)語表中，并且在業(yè)務(wù)模型中提煉業(yè)務(wù)規(guī)則（大部分業(yè)務(wù)規(guī)則都是結(jié)構(gòu)約束）；過程中，拉通團(tuán)隊檢查業(yè)務(wù)實體并達(dá)成共識。否則無法達(dá)成領(lǐng)域建模的目的。

8、領(lǐng)域建模

在上述建模工作流中，領(lǐng)域建模是業(yè)務(wù)建模的一部分，也可以獨立進(jìn)行。但對于領(lǐng)域模型本身，業(yè)界有很多理解。我們追根溯源來整體看看領(lǐng)域建模。

“A domain model captures the most important types of objects in the context of the business. The domain model represents the ‘things’ that exist or events that transpire in the business environment.”

— Ivar Jacobson 領(lǐng)域建模（Domain Modeling）中的“Domain”指問題域，“Domain Modeling”則是一種將現(xiàn)實世界中問題域邊界內(nèi)的業(yè)務(wù)概念、規(guī)則和關(guān)系抽象為軟件模型的方法。

領(lǐng)域建模特指面向特定問題域按關(guān)注點構(gòu)建抽象模型的過程，最終輸出呈現(xiàn)重要概念框架的領(lǐng)域模型。領(lǐng)域建模最早起源于數(shù)據(jù)建模（Data Modeling）并伴隨面向?qū)ο蠓治雠c設(shè)計（Object-Oriented Analysis and Design，OOAD）而發(fā)展，其演變過程也是開發(fā)方法發(fā)展的過程：

1. 80年代，數(shù)據(jù)建模：是一種以數(shù)據(jù)為中心的建模方法，關(guān)注于數(shù)據(jù)的結(jié)構(gòu)和關(guān)系。在數(shù)據(jù)建模階段，模型主要關(guān)注實體、屬性和實體之間的關(guān)系，通常使用實體-關(guān)系圖（Peter Chen/1977）來表示。然而，數(shù)據(jù)建模方法過于關(guān)注數(shù)據(jù)結(jié)構(gòu)，而忽略了業(yè)務(wù)邏輯和行為。
2. 90年代，面向?qū)ο蠓治雠c設(shè)計：OOAD方法克服了數(shù)據(jù)建模和結(jié)構(gòu)化分析與設(shè)計的局限性，將現(xiàn)實世界中的業(yè)務(wù)概念、規(guī)則和關(guān)系抽象為對象、屬性、方法和關(guān)系。面向?qū)ο蠓治雠c設(shè)計方法強調(diào)封裝、繼承和多態(tài)等面向?qū)ο蟮奶匦?，以實現(xiàn)模型的可重用性、可擴(kuò)展性和可維護(hù)性。通常使用統(tǒng)一建模語言（UML）來表示面向?qū)ο蟮哪Ｐ汀?/li>
3. 2000年后，領(lǐng)域驅(qū)動設(shè)計：DDD是在OOAD的基礎(chǔ)上發(fā)展起來的一種設(shè)計方法。它關(guān)注于業(yè)務(wù)領(lǐng)域的概念、規(guī)則和關(guān)系，將現(xiàn)實世界中的業(yè)務(wù)問題抽象為軟件模型。領(lǐng)域驅(qū)動設(shè)計（Domain-Driven Design，DDD）方法提供一系列模式來幫助提煉領(lǐng)域模型，包括實體、值對象、聚合根、領(lǐng)域事件和領(lǐng)域服務(wù)等。

以下領(lǐng)域建模（Domain Model）的出處和解釋，做個匯總：

• 在數(shù)據(jù)建模方法中，領(lǐng)域模型使用的實體關(guān)系模型（Entity-Relation Model）來承載
• 在OOAD方法中，領(lǐng)域模型應(yīng)用分析模型（Analysis Model/Object Model）來承載
• 在DDD方法中，領(lǐng)域模型不局限于表達(dá)形式，核心是問題域中被抽象的知識和呈現(xiàn)要表達(dá)的思想，可以是圖也可以是代碼（源于Eric Evans）。

在我們的實踐中，”領(lǐng)域建模=領(lǐng)域知識+建模方法”，輸出【領(lǐng)域模型】（Domain Model）。所以，領(lǐng)域建模是一系列面向問題域的抽象建模活動，在團(tuán)隊內(nèi)按一致的方法呈現(xiàn)即可稱為領(lǐng)域模型。

可見，領(lǐng)域建模方法是一種用做發(fā)現(xiàn)領(lǐng)域知識的設(shè)計思維。其所構(gòu)建的模型，希望的是對某個有邊界的領(lǐng)域的一個客觀抽象，用于反映領(lǐng)域內(nèi)用戶需求的本質(zhì)，只反應(yīng)我們所關(guān)注的部分，且只反應(yīng)業(yè)務(wù)，和技術(shù)無關(guān)。

在我們實踐的過程中，為了可視而通常用類圖表達(dá)，而且我們發(fā)現(xiàn)它帶來更多的價值和收益：

• 面向問題域呈現(xiàn)概念框架，幫助思考：做為交流工具，共享知識與信息
• 解決需求和設(shè)計意圖中的岐義：為關(guān)鍵概念和系統(tǒng)名詞建立文檔，統(tǒng)一理解
• 控制復(fù)雜度，為實現(xiàn)做指導(dǎo)：防止需求和最終代碼實現(xiàn)走樣
• 沉淀領(lǐng)域知識：模型可以被重用，模型可以被積累
• 支持在模型級別做驗證：快速應(yīng)對和響應(yīng)需求變化

在支付團(tuán)隊的實際業(yè)務(wù)分析和軟件系統(tǒng)構(gòu)建過程中，領(lǐng)域建?；顒痈S著開發(fā)周期進(jìn)行，模型在過程中不斷細(xì)化改進(jìn)，可以貫穿從需求（概念）階段，貫穿分析（分析類圖）設(shè)計階段（設(shè)計類圖）。如下圖：

因此，在支付業(yè)務(wù)的領(lǐng)域建?；顒又?，會涉及不同階段的多種模型，通過靜態(tài)建模和動態(tài)建模的相互完善和驗證，并實現(xiàn)領(lǐng)域知識提煉和業(yè)務(wù)規(guī)則沉淀。相關(guān)活動大致如下：

1、領(lǐng)域建模實例

為了方便理解，回到我們前面餐廳的小例子，其領(lǐng)域模型在概念階段，按關(guān)注的堂食業(yè)務(wù)梳理如下概念/名詞：

可以看到，餐廳運營這個業(yè)務(wù)領(lǐng)域中，需要多種角色保證餐廳的有效運作。如果從改進(jìn)和降本提效的角度看，信息系統(tǒng)可以提供大量改進(jìn)。

實際上在上述模型中還可以補充更多的信息，以發(fā)現(xiàn)和優(yōu)化業(yè)務(wù)場景下關(guān)于效率和成本的內(nèi)容。進(jìn)一步補充實體屬性，如下圖：

再進(jìn)一步處理下，需要在上菜及出菜上分別管理，方便事后核對，如下圖：

事實上，在更大的同類企業(yè)中，還有更多的涉及各環(huán)節(jié)的流程和信息（如采購，財務(wù)..），在這樣的模型呈現(xiàn)出來之后，業(yè)務(wù)系統(tǒng)開發(fā)團(tuán)隊將能更好的從全局來優(yōu)化和設(shè)計信息系統(tǒng)，聚焦改進(jìn)點（如將人工用系統(tǒng)自動化替代），能更好的為目標(biāo)組織降本增效提升競爭力。

通過流程改進(jìn)，交付的目標(biāo)系統(tǒng)實現(xiàn)對人工的優(yōu)化，快速將思路簡化后如下圖。業(yè)務(wù)實體信息化后，由業(yè)務(wù)系統(tǒng)管理并組成了系統(tǒng)本身：

再進(jìn)一步按目標(biāo)業(yè)務(wù)系統(tǒng)進(jìn)行抽象如下，我們提煉出顧客體系，增強顧客聯(lián)系：

我們可以提煉出多個聚合，通過聚合管理一致性邊界。同時對部分實體，有必要的話也可以通過狀態(tài)機描述其狀態(tài)遷移過程，以明確狀態(tài)管理機制。如下，點菜單的狀態(tài)圖。

通過一系列建模，我們可以更直觀的映射到實現(xiàn)過程，方便對齊需求和業(yè)務(wù)目標(biāo)。這樣，當(dāng)運營系統(tǒng)（即業(yè)務(wù)系統(tǒng)）交付后，封裝了人工處理流程，將業(yè)務(wù)實體由物流轉(zhuǎn)為信息流，并實現(xiàn)自動化。當(dāng)然，如果有機器人廚師，則可以成為全自動餐廳。

上述小例子主要有于呈現(xiàn)建模的價值，以及讓團(tuán)隊對目標(biāo)業(yè)務(wù)領(lǐng)域進(jìn)行快速溝通?？赡苡幸恍┎蛔慊蛘卟煌睦斫猓矝]有展示繼續(xù)構(gòu)建的數(shù)據(jù)模型，有想法的同事可以在Xwatt項目里創(chuàng)建自己的思想試驗。

在工具化后可以不斷進(jìn)行迭代達(dá)成團(tuán)隊理想的效果即可。不過，從一個小型餐廳如果深挖也有大大優(yōu)化空間可以看出，大型的企業(yè)/組織背后涉及的復(fù)雜業(yè)務(wù)流程，其背后同樣可能可以找出巨大的優(yōu)化空間。這就是業(yè)務(wù)建模的巨大價值。

針對RUP過程中的業(yè)務(wù)建模方法，國內(nèi)書籍《軟件方法》也給出了相應(yīng)方法沉淀，其中對流程改進(jìn)的模式提煉相應(yīng)指導(dǎo)方法總結(jié)為三點：

1. 物流轉(zhuǎn)信息流：觀察物的流動，提煉物背后承載的信息
2. 改善信息流轉(zhuǎn)：把協(xié)作工作改為由一個軟件系統(tǒng)來完成，多次人的協(xié)作優(yōu)化為一次和系統(tǒng)的協(xié)作
3. 封裝領(lǐng)域邏輯：提煉人工封裝的領(lǐng)域邏輯，改為封裝到軟件系統(tǒng)中去，用軟件系統(tǒng)代替人

本文追根溯源去理解了業(yè)務(wù)建模，相關(guān)細(xì)節(jié)歡迎大家進(jìn)一步論證。

2、小結(jié)

業(yè)務(wù)建模是一個體系化的主題，不同的場景有其合適的用法。通常也不建議對每個項目都進(jìn)行業(yè)務(wù)建模。只有當(dāng)有更多角色直接參與使用該系統(tǒng)，并有更多不同業(yè)務(wù)信息由該系統(tǒng)處理時，業(yè)務(wù)建模才會增加更多價值。

例如，純技術(shù)領(lǐng)域的問題中，與業(yè)務(wù)（Business）無關(guān)，可以無須業(yè)務(wù)建模，你的代碼和數(shù)據(jù)結(jié)構(gòu)就是你的模型抽象；例如，如果只是在現(xiàn)有業(yè)務(wù)系統(tǒng)的接入層網(wǎng)關(guān)中添加一項功能，則不會考慮業(yè)務(wù)建模，因為這不會從根本上改變用戶/組織原本期望的功能，它仍是網(wǎng)關(guān)。

另一方面，如果您正在構(gòu)建一個全新的訂單系統(tǒng)來支持支付業(yè)務(wù)的解決方案，則業(yè)務(wù)建模對于了解該新系統(tǒng)將如何影響相關(guān)業(yè)務(wù)是很有價值的。

因為這個領(lǐng)域流程很復(fù)雜，需要定制解決方案。我們上述的內(nèi)容，核心針對業(yè)務(wù)開發(fā)團(tuán)隊如何快速理解業(yè)務(wù)，從業(yè)務(wù)中梳理需求和提煉領(lǐng)域知識探討了相關(guān)的方法實踐。

四、總結(jié)

回顧軟件開發(fā)行業(yè)，業(yè)務(wù)建模方法隨著IT系統(tǒng)融入商業(yè)領(lǐng)域而蓬勃發(fā)展，因為在原有商業(yè)領(lǐng)域中通過信息系統(tǒng)對原有業(yè)務(wù)流程實施自動化改進(jìn)能提供巨大的增益，這個過程和方法的應(yīng)用能力，也形成了行業(yè)咨詢面向業(yè)務(wù)領(lǐng)域提供業(yè)務(wù)再造/解決方案的核心競爭力。

業(yè)務(wù)建模相對其它方法論有完整的理論基礎(chǔ)（OOAD）和支撐工具，其各環(huán)節(jié)的應(yīng)用在面向行業(yè)深度定制解決方案時發(fā)揮價值（如金融業(yè)核心業(yè)務(wù)系統(tǒng)的解決方案）。

其后，在互聯(lián)網(wǎng)巨浪中快速爆發(fā)的工具型產(chǎn)品，推動了以面向代碼的社區(qū)型敏捷開發(fā)方法的流行，尤其是在數(shù)據(jù)建模由ER模式轉(zhuǎn)向NoSQL，而這個過程中面向業(yè)務(wù)領(lǐng)域的開發(fā)方法，相對在互聯(lián)網(wǎng)社區(qū)的影響力在減弱。

但當(dāng)復(fù)雜業(yè)務(wù)系統(tǒng)再次由線下融入到線上之后，我們可以看到相關(guān)的方法論又再次進(jìn)入視野，比如電商、比如物流，比如支付、金融等等。但隨著行業(yè)競爭的加劇相關(guān)業(yè)務(wù)分析方法也在逐步演化，出現(xiàn)了一些不同的簡化的建模方法，如Aglie Modeling。

業(yè)務(wù)建模的價值在于，通過一場思想實驗讓團(tuán)隊以相對低成本、輕量的方式真實的還原業(yè)務(wù)流程；通過抽象模型提煉業(yè)務(wù)的核心領(lǐng)域知識以還原業(yè)務(wù)本質(zhì) ，提升團(tuán)隊對業(yè)務(wù)領(lǐng)域一致和深入的理解，來促進(jìn)業(yè)務(wù)和技術(shù)更好的映射。

業(yè)務(wù)建模過程，幫助我們理解構(gòu)建的業(yè)務(wù)系統(tǒng)背后所服務(wù)的目標(biāo)組織（客戶），理解其對業(yè)務(wù)系統(tǒng)功能的底層訴求，理解用戶使用我們的業(yè)務(wù)系統(tǒng)/產(chǎn)品/服務(wù)的驅(qū)動因素。

這些因素可能是降低成本、提高質(zhì)量或縮短產(chǎn)品上市時間等目標(biāo)。我們能通過業(yè)務(wù)建模來定位問題或找出改進(jìn)的機會，并在建模這種輕量的活動中完成對業(yè)務(wù)改進(jìn)的驗證。

流行在變，但經(jīng)典永存。業(yè)務(wù)建模所融入的OO方法/領(lǐng)域建模方法/業(yè)務(wù)流程改進(jìn)方法，仍在為業(yè)務(wù)開發(fā)帶來的有力競爭力。

當(dāng)今LLM再次為軟件開發(fā)行業(yè)掀起巨浪時，做為Prompt Engineering背后的本質(zhì)也是“如何理解業(yè)務(wù)并結(jié)構(gòu)化的陳述業(yè)務(wù)需求”，這與業(yè)務(wù)建模方法為業(yè)務(wù)開發(fā)賦予的理解問題域的能力正好契合，“聲明式的方法+結(jié)構(gòu)化抽象并逐步分解問題”的思維不會過時，AI時代甚至有機會賦予業(yè)務(wù)開發(fā)新價值。

附錄

附錄1

上述所有模型使用微信支付瓦特團(tuán)隊的建模工具完成，歡迎issue。按需定制的建模工具。

附錄2

RUP過程中的業(yè)務(wù)序列圖，業(yè)務(wù)實體呈現(xiàn)出來（與一些方法的表示法有差異),但個人認(rèn)為RUP更好表達(dá)業(yè)務(wù)現(xiàn)狀，因為目標(biāo)組織始終存在人工流程和非智能系統(tǒng)(業(yè)務(wù)工人在處理業(yè)務(wù)用例時，仍存在重要的要處理和使用的重要且有價值的”事物”),這類事物在RUP過程的方法中需要被建模為業(yè)務(wù)實體。

附錄3

業(yè)務(wù)建模的ECB模式，經(jīng)查最早由Objectory方法合入RUP過程（Ratinal Unified Process）

參考資料：

• IBM / Rational Software 《Business Modeling with the UML and Rational Suite Analyst Studio》
• Philippe Kruchten《The Rational Unified Process-An Introduction-Third Editon》
• Grady Booch 《Object-Oriented Analysis And Design with Application Third Edition》
• Bernd Bruegge《Object-Oriented Software Engineering》
• Ivar Jacobson《Object-Oriented Software Engineering-A Use Case Driven Approach》
• Craig Larman《Applying UML and Patterns –An Introduction to Object-Oriented Analysis and Design and the Unified Process》
• Martin Fowler《Patterns of Enterprise Application Architecture》
• Eric Evans 《Domain Driven Design – Tackling Complexity in the Heart of Software》
• Vaughn Vernon 《Implementing Domain-Driven Design》
• Peter Chen《The entity-relationship model : toward a unified view of data》
• 潘加宇《軟件方法》