中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

業(yè)務(wù)流程是促進(jìn)這種有效協(xié)作的重要概念。在非科技行業(yè)的各類公司中，組織的業(yè)務(wù)方面與現(xiàn)有信息技術(shù)之間存在差距?？s小組織和技術(shù)之間的差距非常重要，因?yàn)樵诋?dāng)今充滿活力和競(jìng)爭(zhēng)的市場(chǎ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)逐步對(duì)業(yè)務(wù)流程不斷改進(jìn)（如信息流/資金流）。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2、做對(duì)需求

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

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

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

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

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

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

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

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

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

1、模型（Model）

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

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

2、建模（Modeling）

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

建模使我們能夠通過分而治之的方法處理復(fù)雜性：對(duì)于我們想要解決的每種類型的問題，我們構(gòu)建一個(gè)僅關(guān)注與問題相關(guān)的問題的模型。一般來(lái)說，建模的重點(diǎn)是建立一個(gè)足夠簡(jiǎ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)險(xiǎn)增加成功概率。

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

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

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

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

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

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

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

可見，業(yè)務(wù)建模很好的應(yīng)對(duì)了我們?cè)谧鲂枨髸r(shí)所提到的挑戰(zhàn)：理解業(yè)務(wù)，做對(duì)需求甚至洞察需求。

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

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

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

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

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

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

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

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

業(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í)行者希望通過和組織交互獲得的由組織提供的價(jià)值。業(yè)務(wù)用例必須支持業(yè)務(wù)目標(biāo)。目標(biāo)領(lǐng)域中的業(yè)務(wù)流程，由業(yè)務(wù)用例和其實(shí)現(xiàn)來(lái)表示。建模業(yè)務(wù)用例和參與者的目的是描述客戶和關(guān)聯(lián)方如何做業(yè)務(wù)。呈現(xiàn)直接涉及客戶或關(guān)聯(lián)方的活動(dòng)，以及間接涉及外部各方的支持或管理任務(wù)。
• 業(yè)務(wù)所需功能的模型，用作識(shí)別目標(biāo)組織中的角色和對(duì)外交付的價(jià)值（可交付件）

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

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

其次，也需要以下輸出做為補(bǔ)充：

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

參考RUP過程示例模型：

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

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

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

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

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

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

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

為消費(fèi)者（即顧客）提供餐飲；

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在第一次迭代時(shí)，需要評(píng)估組織狀態(tài)并確定建模目標(biāo)。再?zèng)Q定如何迭代。

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

如果不需要對(duì)整體業(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ù)分析模型

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

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

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

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

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

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

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

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

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

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

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

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

制定組織愿景，識(shí)別涉眾：要解決什么問題，交付的業(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ù)模型為起點(diǎn)對(duì)業(yè)務(wù)流程改進(jìn)或重新思考

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

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

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

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

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

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

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

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

①三類自動(dòng)化方式

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

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

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

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

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

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

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

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

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

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

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

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

8、領(lǐng)域建模

在上述建模工作流中，領(lǐng)域建模是業(yè)務(wù)建模的一部分，也可以獨(dú)立進(jìn)行。但對(duì)于領(lǐng)域模型本身，業(yè)界有很多理解。我們追根溯源來(lái)整體看看領(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)實(shí)世界中問題域邊界內(nèi)的業(yè)務(wù)概念、規(guī)則和關(guān)系抽象為軟件模型的方法。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

上述小例子主要有于呈現(xiàn)建模的價(jià)值，以及讓團(tuán)隊(duì)對(duì)目標(biāo)業(yè)務(wù)領(lǐng)域進(jìn)行快速溝通。可能有一些不足或者不同的理解，也沒有展示繼續(xù)構(gòu)建的數(shù)據(jù)模型，有想法的同事可以在Xwatt項(xiàng)目里創(chuàng)建自己的思想試驗(yàn)。

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

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

1. 物流轉(zhuǎn)信息流：觀察物的流動(dòng)，提煉物背后承載的信息
2. 改善信息流轉(zhuǎn)：把協(xié)作工作改為由一個(gè)軟件系統(tǒng)來(lái)完成，多次人的協(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ù)建模是一個(gè)體系化的主題，不同的場(chǎng)景有其合適的用法。通常也不建議對(duì)每個(gè)項(xiàng)目都進(jìn)行業(yè)務(wù)建模。只有當(dāng)有更多角色直接參與使用該系統(tǒng)，并有更多不同業(yè)務(wù)信息由該系統(tǒng)處理時(shí)，業(yè)務(wù)建模才會(huì)增加更多價(jià)值。

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

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

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

四、總結(jié)

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

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

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

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

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

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

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

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

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

附錄

附錄1

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

附錄2

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

附錄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》
• 潘加宇《軟件方法》