2023年9月9—10日，人人都是產(chǎn)品經(jīng)理聯(lián)合騰訊大講堂舉辦的【2023產(chǎn)品經(jīng)理大會(huì)·北京站】完美落幕。和度軟件CEO、軟件地圖創(chuàng)始人程杰老師，為我們帶來《B端數(shù)字化產(chǎn)品的敏捷設(shè)計(jì)建模技術(shù)與實(shí)戰(zhàn)方法》為題的分享，本文為演講內(nèi)容實(shí)錄。目前大會(huì)回放已上架，戳此購買，即可收看回放：https://996.pm/7gX2B

今天我分享的主題是“B端數(shù)字化產(chǎn)品的敏捷設(shè)計(jì)建模技術(shù)與實(shí)戰(zhàn)方法”，主要分四個(gè)維度進(jìn)行：

1. 問題與分析；
2. 研發(fā)與應(yīng)用；
3. 技術(shù)與愿景；
4. 實(shí)戰(zhàn)方法。

一、問題與分析

這幅圖是軟件工程當(dāng)中的一張經(jīng)典圖片，它反映了軟件工程里各個(gè)環(huán)節(jié)的溝通失真問題。而溝通失真會(huì)給軟件工程帶來很多問題，比如返工多、加班多；變更多、應(yīng)對慢；用戶認(rèn)可難，實(shí)施難、上線難、驗(yàn)收難；包括預(yù)算超支嚴(yán)重，甲乙雙方都覺得有所虧損，合作瀕于崩潰。

實(shí)際上，當(dāng)我們跳出軟件工程行業(yè)，會(huì)發(fā)現(xiàn)，其他的工程行業(yè)在設(shè)計(jì)環(huán)節(jié)都會(huì)輸出規(guī)范化、結(jié)構(gòu)化的設(shè)計(jì)圖紙，但是軟件工程到現(xiàn)在為止還是使用非結(jié)構(gòu)化的設(shè)計(jì)文檔。很諷刺的一點(diǎn)，即創(chuàng)造 AI 的軟件工程實(shí)際上是很“落后”的。

所以，軟件工程溝通失真的根本原因在于：設(shè)計(jì)環(huán)節(jié)沒有輸出可以“降低溝通成本、驅(qū)動(dòng)工程全流程、降低系統(tǒng)性風(fēng)險(xiǎn)”的結(jié)構(gòu)化、可視化的設(shè)計(jì)模型。各個(gè)環(huán)節(jié)當(dāng)中的溝通失真問題，實(shí)際上是設(shè)計(jì)環(huán)節(jié)出了問題。

但其實(shí)軟件工程行業(yè)是有設(shè)計(jì)建模技術(shù)的。2002年OMG提出了MDA（模型驅(qū)動(dòng)的軟件開發(fā)架構(gòu)），但大家并沒有將其投入使用，原因在于：

1. UML建模慢，跟不上開發(fā)節(jié)奏；
2. UML圖例繁雜，閱讀效率低，溝通成本高；
3. 需求發(fā)生變更后，CIM/PIM/PSM三個(gè)模型都改嗎？還是只改部分？前者面臨效率問題，后者則面臨著一致性問題。

所以可以得出一個(gè)結(jié)論——軟件工程行業(yè)亟需一套實(shí)用的軟件設(shè)計(jì)建模技術(shù)與系統(tǒng)，解決以“大量實(shí)際軟件工程仍在使用非結(jié)構(gòu)化設(shè)計(jì)文檔”為表征的行業(yè)性設(shè)計(jì)不規(guī)范、設(shè)計(jì)不可視、設(shè)計(jì)質(zhì)量低的問題，及其引起的軟件開發(fā)與運(yùn)維過程中的“溝通失真”與大量浪費(fèi)。

二、研發(fā)與應(yīng)用

基于以上分析，我們做了一個(gè)自研項(xiàng)目，叫軟件地圖，我們希望研發(fā)出一套實(shí)用的軟件設(shè)計(jì)建模技術(shù)和系統(tǒng)，應(yīng)滿足以下要求：

1. 項(xiàng)目各方對于設(shè)計(jì)模型都能夠讀懂、理解，而且閱讀效率高；
2. 設(shè)計(jì)建模快、變更快，設(shè)計(jì)模型可詳可略、靈活可控，能適應(yīng)開發(fā)節(jié)奏；
3. 設(shè)計(jì)規(guī)范性和質(zhì)量大幅提升，可以快速、充分地評審設(shè)計(jì)，大幅降低項(xiàng)目風(fēng)險(xiǎn)；
4. 由設(shè)計(jì)模型可以自動(dòng)生成程序源碼、測試用例，大幅降低開發(fā)成本；
5. 可支撐大型項(xiàng)目協(xié)同化設(shè)計(jì)建模；
6. 學(xué)習(xí)快、上手快。

總結(jié)一點(diǎn)，即：快，才實(shí)用。

整體項(xiàng)目于2020年10月份啟動(dòng)，21年9月份，我們上線了第一版，10月份的時(shí)候，軟件地圖就已經(jīng)應(yīng)用到一個(gè)千萬級的軟件定制化開發(fā)項(xiàng)目當(dāng)中。23年2月份，我們發(fā)布了第二版應(yīng)用，并在3月份應(yīng)用到在線系統(tǒng)運(yùn)維當(dāng)中；6月份則發(fā)布了第三版。

主要功能如圖所示，包括了新型制圖功能、模板庫、全流程設(shè)計(jì)建模功能，等等。目的即降低溝通成本，提升可視化功能與自動(dòng)化功能。

這里分享一個(gè)案例。

2021年，我們需要為一家服裝外貿(mào)龍頭企業(yè)搭建全流程的數(shù)字化運(yùn)營平臺，即服裝ERP。這個(gè)項(xiàng)目屬于從0到1式的全定制開發(fā)，業(yè)務(wù)邏輯非常復(fù)雜，包括2800+系統(tǒng)功能、1000+用戶界面、600+數(shù)據(jù)表、對接66個(gè)外部系統(tǒng)接口，對軟件設(shè)計(jì)能力有很大挑戰(zhàn)，一不小心即會(huì)陷入設(shè)計(jì)黑洞。在當(dāng)時(shí)，我?guī)ьI(lǐng)20多個(gè)人，分為7個(gè)開發(fā)小組，使用軟件地圖在線協(xié)同設(shè)計(jì)建模，并取得了顯著成果：

1. 提升了設(shè)計(jì)規(guī)范性、質(zhì)量和效率，降低了溝通成本；
2. 自動(dòng)生成了服務(wù)端程序50%的源碼；
3. 程序員每人每天平均產(chǎn)出300行有效源碼（不含自動(dòng)生成的代碼），高效保障項(xiàng)目成功交付。

而從案例可以看出，當(dāng)設(shè)計(jì)質(zhì)量提高、溝通成本下降，效益也就有所提升。

再分享一個(gè)案例，當(dāng)時(shí)，全球最大的針織服裝制造集團(tuán)需要應(yīng)用軟件地圖，對十多個(gè)在線核心業(yè)務(wù)系統(tǒng)進(jìn)行逆向建模，理清各系統(tǒng)復(fù)雜邏輯，構(gòu)建在線軟件設(shè)計(jì)圖紙，大幅提高運(yùn)維效率，降低迭代升級風(fēng)險(xiǎn)，最終獲得了收益：

為什么運(yùn)用了軟件地圖之后，設(shè)計(jì)效率、運(yùn)維效率可以得到大幅提升，開發(fā)成本和BUG率可以被大幅降低？這里涉及了一個(gè)核心技術(shù)——敏捷設(shè)計(jì)建模技術(shù)。接下來講講原因所在。

三、技術(shù)與愿景

我們的模型結(jié)構(gòu)涵蓋了幾個(gè)方面，包括業(yè)務(wù)模型、產(chǎn)品模型、程序模型：

• 業(yè)務(wù)模型：包括業(yè)務(wù)架構(gòu)、業(yè)務(wù)流程、業(yè)務(wù)對象；
• 產(chǎn)品模型：包括數(shù)據(jù)表、系統(tǒng)功能、用戶界面、接口等；
• 程序模型：包括子系統(tǒng)、API、DTO。

第一個(gè)核心技術(shù)，即業(yè)務(wù)模型中心驅(qū)動(dòng)（BCD），它解決了 MDA 三個(gè)階段性模型的問題。而在分析與設(shè)計(jì)的過程當(dāng)中，始終只有一個(gè)模型，這個(gè)模型集成了業(yè)務(wù)模型、產(chǎn)品模型跟程序模型；并且始終以業(yè)務(wù)模型為中心，迭代式驅(qū)動(dòng)構(gòu)建產(chǎn)品模型和程序模型。業(yè)務(wù)模型不會(huì)被拋棄，而是會(huì)迭代出結(jié)構(gòu)化的業(yè)務(wù)邏輯，即數(shù)據(jù)能力——算法，并被其他模型所調(diào)用。如此，相較于MDA，BCD可以大幅提升建模效率、一致性、集成性和變更敏捷性。

如何理解？即在分析、設(shè)計(jì)與開發(fā)過程中，使用了一個(gè)大的相同結(jié)構(gòu)，避免異構(gòu)現(xiàn)象的發(fā)生，也降低或避免結(jié)構(gòu)轉(zhuǎn)換之間的溝通失真與損耗。我們要求產(chǎn)品經(jīng)理一開始就使用MVC設(shè)計(jì)框架，也方便了后續(xù)和研發(fā)團(tuán)隊(duì)之間的溝通。

那么我們是如何開展的呢？從需求開始（需求包括現(xiàn)狀流程以及基于現(xiàn)狀流程的系統(tǒng)需求），我們分析得出過程中的業(yè)務(wù)對象（B端需求分析一定要分析出業(yè)務(wù)對象），隨后分析得出處理業(yè)務(wù)對象的能力，即數(shù)據(jù)結(jié)構(gòu)+數(shù)據(jù)能力。由數(shù)據(jù)能力，則可以推出系統(tǒng)功能。而在考慮系統(tǒng)功能的用例設(shè)計(jì)時(shí)，必然會(huì)涉及到輸入輸出界面，由此驅(qū)動(dòng)開發(fā)界面。在界面的詳細(xì)數(shù)據(jù)項(xiàng)得到用戶確認(rèn)后，再結(jié)合業(yè)務(wù)對象的數(shù)據(jù)結(jié)構(gòu)，即可合起來，共同構(gòu)成數(shù)據(jù)表以及表字段。最后，數(shù)據(jù)能力會(huì)演化為服務(wù)端的API，界面中的算法則演化為用戶端的API。

第二個(gè)核心技術(shù)，即可視化動(dòng)態(tài)樹。傳統(tǒng)的圖元組裝式建模技術(shù)是有較大弊端的：

1. 閱讀效率低；沒有顯性的閱讀路徑，圖源多了以后，圖很凌亂，有效承載的信息量大大受限；再者，表達(dá)顆粒度固化，無法在一張圖當(dāng)中按需切換，查看全局和細(xì)節(jié)；
2. 建模效率低：調(diào)整圖元位置、大小，都相對費(fèi)時(shí)。

所以，我們所有的模型構(gòu)建統(tǒng)一使用樹狀圖建模，即所有的模型都是思維導(dǎo)圖式的，預(yù)定義了 100 多種具有特定語義和樣式的模型節(jié)點(diǎn)，實(shí)現(xiàn)了模型的結(jié)構(gòu)化、可視化。此外，樹狀圖本身是可聚合、可發(fā)散的，符合人類的閱讀和理解習(xí)慣。而建模時(shí)無需要布局對齊、調(diào)整大小、可快速鍵盤操作等優(yōu)勢，則大幅提升了建模效率。某種程度上，我們其實(shí)是做了一個(gè)為軟件工程而定制的思維導(dǎo)圖。

第三個(gè)核心技術(shù)，即業(yè)務(wù)組件模板，即我們可以一鍵生成圍繞業(yè)務(wù)對象的設(shè)計(jì)制品，包括數(shù)據(jù)表、系統(tǒng)功能、界面原型等等。而設(shè)計(jì)同學(xué)此時(shí)只需要明確分析得出的業(yè)務(wù)單據(jù)需匹配什么模板，之后一鍵生成好即可。這大大提升了設(shè)計(jì)效率與設(shè)計(jì)規(guī)范度，實(shí)現(xiàn)了模板化。

第四個(gè)核心技術(shù)，綠色的模型轉(zhuǎn)換技術(shù)。模型最終要轉(zhuǎn)換成程序源碼，同時(shí)底層軟件包由用戶單位自行設(shè)定，即用戶對生成的程序源碼完全自主可控。

總結(jié)可得，軟件地圖在多維度上取得了“敏捷化、實(shí)用化”的突破，和UML相比，軟件地圖在閱讀效率、設(shè)計(jì)信息集成度、設(shè)計(jì)效率、建模效率、變更效率等各方面都取得了很大突破。

我們希望通過敏捷化、實(shí)用化的軟件設(shè)計(jì)建模技術(shù)和工具促進(jìn)軟件工程在分析和設(shè)計(jì)這兩個(gè)上游階段的數(shù)字化轉(zhuǎn)型，在源頭上解決溝通難、返工多、預(yù)算高、風(fēng)險(xiǎn)高、運(yùn)維壓力大和應(yīng)變慢等普遍存在的軟件工程問題。

另外，我們希望可以鏈接大模型平臺，通過“軟件設(shè)計(jì)模型+編程大模型”，構(gòu)建“數(shù)字化設(shè)計(jì)+AI編程”新型軟件工程模式，優(yōu)化軟件工程成本結(jié)構(gòu)，大幅降低軟件工程成本，大幅縮短軟件工程交期，大幅提升軟件工程質(zhì)量。

同時(shí)，我們還希望助力千行百業(yè)數(shù)字化轉(zhuǎn)型，構(gòu)建開源設(shè)計(jì)社區(qū)。

其一，通過軟件邏輯的結(jié)構(gòu)化、可視化和模板化，合作構(gòu)建各行業(yè)應(yīng)用軟件設(shè)計(jì)模板庫，大幅提升各行業(yè)數(shù)字化轉(zhuǎn)型落地速度和質(zhì)量，大幅降低成本和風(fēng)險(xiǎn)，大幅減少數(shù)字化爛尾工程和豆腐渣工程，促進(jìn)更多企業(yè)數(shù)字化轉(zhuǎn)型“敢轉(zhuǎn)、愿轉(zhuǎn)、轉(zhuǎn)好”。

其二，通過大幅降低軟件設(shè)計(jì)的能力門檻，在千行百業(yè)中普及推廣軟件設(shè)計(jì)能力，為各企業(yè)及機(jī)構(gòu)培養(yǎng)數(shù)字化人才，加速業(yè)務(wù)與IT融合。

其三，推動(dòng)ERP等重點(diǎn)開源設(shè)計(jì)項(xiàng)目，對標(biāo)GITHUB，構(gòu)建開源設(shè)計(jì)社區(qū)。

四、實(shí)戰(zhàn)方法

我們將軟件全棧設(shè)計(jì)過程進(jìn)行了定義，包括八大過程——需求分析、業(yè)務(wù)藍(lán)圖設(shè)計(jì)、人機(jī)交互設(shè)計(jì)、系統(tǒng)接口設(shè)計(jì)、數(shù)據(jù)庫設(shè)計(jì)、算法設(shè)計(jì)、程序設(shè)計(jì)和測試設(shè)計(jì)；和產(chǎn)品經(jīng)理更密切相關(guān)的可能是前三個(gè)部分，后面將詳細(xì)講述。

同時(shí)我們也定義了各個(gè)過程的產(chǎn)出物，以及在線系統(tǒng)逆向建模過程。

1. 需求分析

關(guān)于需求分析，我們定義了5個(gè)活動(dòng)，包括：構(gòu)建業(yè)務(wù)地圖、分析現(xiàn)狀業(yè)務(wù)流程、梳理系統(tǒng)需求、分析業(yè)務(wù)對象和確認(rèn)業(yè)務(wù)需求。

首先，建立需求分析的框架，防止用戶單位“飄”出去。這個(gè)框架可以稱之為業(yè)務(wù)地圖。什么是業(yè)務(wù)地圖？即多層級的業(yè)務(wù)模塊以及下面掛載的業(yè)務(wù)流程。

接著，繪制流程圖。我們需要進(jìn)一步劃分，構(gòu)建流程內(nèi)的結(jié)構(gòu)。可以按照工作崗位和業(yè)務(wù)事件劃分業(yè)務(wù)作業(yè)，然后按先后順序、因果關(guān)系，串接業(yè)務(wù)作業(yè)，這就構(gòu)成了業(yè)務(wù)流程圖。

注意，這是現(xiàn)狀業(yè)務(wù)流程圖，現(xiàn)狀業(yè)務(wù)流程需要快速構(gòu)建，而后描述每一個(gè)業(yè)務(wù)作業(yè)的場景和數(shù)據(jù)處理。這里有一個(gè)觀點(diǎn)，即理解了業(yè)務(wù)數(shù)據(jù)，才算是真正理解了業(yè)務(wù)場景。一定要花時(shí)間研究業(yè)務(wù)數(shù)據(jù)。我們可以將所有業(yè)務(wù)數(shù)據(jù)列出來，其后將樣本數(shù)據(jù)全部放置其上，后續(xù)于此基礎(chǔ)上梳理系統(tǒng)需求，這個(gè)時(shí)候，梳理的每個(gè)系統(tǒng)需求都要落到一個(gè)業(yè)務(wù)作業(yè)當(dāng)中去。

同時(shí)注意，千萬不要照搬業(yè)務(wù)人員所講的話，一定要做分類與歸納。

最終，需求分析一定要分析出業(yè)務(wù)作業(yè)處理的業(yè)務(wù)對象。在B端場景下，業(yè)務(wù)對象可能是業(yè)務(wù)單據(jù)，而業(yè)務(wù)單據(jù)承載著系統(tǒng)需求，我們需要將系統(tǒng)需求落地到業(yè)務(wù)對象的管理場景與應(yīng)用場景，根據(jù)樣本數(shù)據(jù)與系統(tǒng)需求，分析業(yè)務(wù)對象的數(shù)據(jù)結(jié)構(gòu)。

2. 業(yè)務(wù)藍(lán)圖設(shè)計(jì)

業(yè)務(wù)藍(lán)圖設(shè)計(jì)包括5個(gè)動(dòng)作：設(shè)計(jì)核心數(shù)據(jù)邏輯、定義數(shù)據(jù)能力、設(shè)計(jì)功能地圖、設(shè)計(jì)目標(biāo)業(yè)務(wù)流程、確認(rèn)業(yè)務(wù)藍(lán)圖。這里重點(diǎn)要理解核心數(shù)據(jù)邏輯：

核心數(shù)據(jù)邏輯=數(shù)據(jù)結(jié)構(gòu)+數(shù)據(jù)狀態(tài)+數(shù)據(jù)演變

核心數(shù)據(jù)邏輯是業(yè)務(wù)模型的核心，是整個(gè)系統(tǒng)的地基，即便不是開發(fā)同學(xué)，也需要在抽象層次上理解數(shù)據(jù)邏輯，否則就只能被開發(fā)同學(xué)反復(fù)“折磨”。所以，核心數(shù)據(jù)邏輯為整個(gè)設(shè)計(jì)過程提供了可行性邏輯內(nèi)核，驅(qū)動(dòng)后續(xù)設(shè)計(jì)，并持續(xù)迭代。另外需注意，B端數(shù)字化產(chǎn)品設(shè)計(jì)，切忌“界面原型驅(qū)動(dòng)”。

首先，設(shè)計(jì)核心數(shù)據(jù)邏輯的第一步是構(gòu)建業(yè)務(wù)對象的數(shù)據(jù)結(jié)構(gòu)與數(shù)據(jù)關(guān)系，我們需要定義構(gòu)成業(yè)務(wù)對象的數(shù)據(jù)元素。數(shù)據(jù)元素的顆粒度非常重要，但不需要到非常明細(xì)的數(shù)據(jù)字段。而某個(gè)數(shù)據(jù)元素與業(yè)務(wù)對象或上級元素的關(guān)系只有兩種類型：最多1份或最多N份。

這個(gè)數(shù)據(jù)結(jié)構(gòu)不需要像“類”那樣復(fù)雜，只需要弄清楚其包含關(guān)系即可，比如這個(gè)款式檔案應(yīng)該由哪幾份數(shù)據(jù)構(gòu)成，可能有一份正式版數(shù)據(jù)、一份變更版數(shù)據(jù)，最多再有一份快照版數(shù)據(jù)。至于這些數(shù)據(jù)將會(huì)被存儲(chǔ)在哪些表格中，則是自然而然的事情。

接著，我們需要按需定義業(yè)務(wù)對象每個(gè)數(shù)據(jù)元素的狀態(tài)參數(shù)。

最終，我們便得到了數(shù)據(jù)演變圖，在這里，數(shù)據(jù)演變圖設(shè)計(jì)了業(yè)務(wù)對象及其數(shù)據(jù)元素的生命周期，由若干 {數(shù)據(jù)能力+其產(chǎn)生的數(shù)據(jù)變化} 二元節(jié)點(diǎn)組構(gòu)成，表達(dá)了業(yè)務(wù)對象的核心邏輯。

綜合以上，我便可以在抽象層次上將數(shù)據(jù)演變展示出來，既不需要編程，也沒有數(shù)據(jù)表的設(shè)計(jì)，僅僅是數(shù)據(jù)結(jié)構(gòu)+概要算法。

基于上述設(shè)計(jì)得出的數(shù)據(jù)演變，隨后，我們逐個(gè)定義數(shù)據(jù)演變圖中的數(shù)據(jù)能力，規(guī)范化定義數(shù)據(jù)能力的名稱和代碼（隨后我們會(huì)在這一基礎(chǔ)上生成API）。

接著便是定義系統(tǒng)功能，結(jié)合多層級的功能模塊，以業(yè)務(wù)架構(gòu)為基礎(chǔ)，橫向擴(kuò)展通用功能模塊和基礎(chǔ)功能模塊，縱向擴(kuò)展到業(yè)務(wù)對象級模塊。

隨后，基于新的系統(tǒng)功能設(shè)計(jì)目標(biāo)業(yè)務(wù)流程。目標(biāo)業(yè)務(wù)流程可以理解為強(qiáng)制性的作業(yè)規(guī)范，它的要求會(huì)更為嚴(yán)謹(jǐn)。

在業(yè)務(wù)流程設(shè)計(jì)好了之后，我們需要更加細(xì)致地設(shè)計(jì)業(yè)務(wù)作業(yè)，說明在什么場景中執(zhí)行該業(yè)務(wù)作業(yè)以及主要執(zhí)行步驟、執(zhí)行過程需要使用哪些系統(tǒng)功能、注意事項(xiàng)，等等。

在目標(biāo)業(yè)務(wù)流程得到用戶單位認(rèn)可，且業(yè)務(wù)流程是構(gòu)建在可行性的數(shù)據(jù)邏輯的基礎(chǔ)之上時(shí)，我們便可進(jìn)入到人機(jī)交互設(shè)計(jì)了。

3. 人機(jī)交互設(shè)計(jì)

總共包括5個(gè)動(dòng)作——設(shè)計(jì)功能用例、設(shè)計(jì)界面地圖、制作界面原型、設(shè)計(jì)集成用例、確認(rèn)系統(tǒng)原型。

首先，功能用例可能如圖所示，包含了用戶操作和系統(tǒng)相應(yīng)的序列。

接著，設(shè)計(jì)界面地圖，大致步驟如下：

1）設(shè)計(jì)界面架構(gòu)（多層級界面入口）

2）定義用戶界面 & 設(shè)計(jì)界面要素

界面要素是下階段制作界面原型的界面關(guān)鍵元素，包括：

• 數(shù)據(jù)控件及其事件、事件中的界面流轉(zhuǎn)與模式轉(zhuǎn)化；
• 界面事件、事件中的界面流轉(zhuǎn)與模式轉(zhuǎn)化。

3）生成界面地圖

下一個(gè)動(dòng)作便是制作界面原型。注意，每個(gè)界面可能有多個(gè)模式，如果原型缺失界面模式，將導(dǎo)致原型確認(rèn)失效，這也是后續(xù)發(fā)生設(shè)計(jì)變更的重要原因之一。

接著，設(shè)計(jì)集成用例，即集成多個(gè)相關(guān)功能用例，在系統(tǒng)響應(yīng)后面設(shè)置集成界面事件、界面模式等。集成用例是重要的設(shè)計(jì)產(chǎn)出物，因?yàn)樗梢赃M(jìn)行仿真演示，與客戶確認(rèn)系統(tǒng)原型，并在系統(tǒng)上線后培訓(xùn)用戶。此外，它還可以導(dǎo)出PRD、測試用例、產(chǎn)品操作手冊。

最終，便是確認(rèn)系統(tǒng)原型，按集成用例預(yù)設(shè)路徑確定性地與客戶確認(rèn)。

除了上面所說的三個(gè)過程，此外還有：

系統(tǒng)接口設(shè)計(jì)，包括：定義外聯(lián)系統(tǒng)、設(shè)計(jì)接口地圖、設(shè)計(jì)外聯(lián)接口參數(shù)、設(shè)計(jì)接口功能參數(shù)、確認(rèn)系統(tǒng)接口。

數(shù)據(jù)庫設(shè)計(jì)，包括：定義數(shù)據(jù)庫、設(shè)計(jì)數(shù)據(jù)地圖、設(shè)計(jì)數(shù)據(jù)標(biāo)準(zhǔn)、設(shè)計(jì)數(shù)據(jù)表、生成數(shù)據(jù)庫。

如圖所示，這個(gè)數(shù)據(jù)地圖清晰地標(biāo)識出了數(shù)據(jù)模塊、模塊當(dāng)中的業(yè)務(wù)對象和相應(yīng)的數(shù)據(jù)表，點(diǎn)擊之后，即可查看數(shù)據(jù)表詳情。

算法設(shè)計(jì)，包括設(shè)計(jì)數(shù)據(jù)能力算法、設(shè)計(jì)用戶界面算法、設(shè)計(jì)接口功能算法、設(shè)計(jì)定時(shí)功能算法。

程序設(shè)計(jì)，包括設(shè)計(jì)子系統(tǒng)、設(shè)計(jì)程序地圖、設(shè)計(jì)DTO、設(shè)計(jì)API、生成程序源碼。

如圖所示，在子系統(tǒng)中，我們會(huì)設(shè)計(jì)程序模塊以及相應(yīng)的類。在形成程序地圖、設(shè)計(jì)API后，最終，則可以生成程序源碼，而這些程序源碼，都為低價(jià)值編程代碼。

測試設(shè)計(jì)，包括配置API測試環(huán)境、生成API測試腳本、設(shè)計(jì)集成用例、生成集成測試用例。

從前面所講的內(nèi)容來看，是不是覺得有些復(fù)雜？因?yàn)樵O(shè)計(jì)已經(jīng)走向細(xì)顆粒度的結(jié)構(gòu)化，而這必然帶來較大的工作量。這個(gè)時(shí)候，我們需要提供業(yè)務(wù)組件模板庫，以提高設(shè)計(jì)效率，降低設(shè)計(jì)門檻。模板里面包含：

• 基礎(chǔ)組件：數(shù)據(jù)字典、組織管理、用戶管理、權(quán)限管理、文件管理等；
• 通用組件：按有無狀態(tài)、單/多崗管理、單/多版、單/多層、界面模式等劃分；
• 專用組件：按行業(yè)、應(yīng)用劃分，例如：銀行、電力、制造業(yè)ERP、制造業(yè)MES等。

我們一直在說“不要重復(fù)造輪子”，但實(shí)際上“重復(fù)造輪子”的事情一直在發(fā)生，是因?yàn)槲覀儗I(yè)務(wù)組件固化在了代碼級別?；谶@點(diǎn)，我們的處理策略便是將其抽象至設(shè)計(jì)圖紙層級，這樣子改起來快，看起來也更清楚、明白。

我們也希望可以建立一個(gè)開源設(shè)計(jì)社區(qū)，里面有大量的模板、參考資料和資源，方便大家查找。

大會(huì)直播回放

目前大會(huì)回放已上架，戳此購買，即可收看回放：https://996.pm/7gX2B