編輯導(dǎo)讀：產(chǎn)品經(jīng)理在工作中會接觸很多前所未有的領(lǐng)域，學(xué)習(xí)到很多新知識。本文作者在負(fù)責(zé)中后臺產(chǎn)品相關(guān)工作中漸漸對軟件工程、架構(gòu)設(shè)計有了越來越多的理解，同時也補(bǔ)充學(xué)習(xí)了包括微服務(wù)架構(gòu)、中臺體系、領(lǐng)域驅(qū)動設(shè)計等技術(shù)知識體系。本文整理了過往產(chǎn)品架構(gòu)設(shè)計中的一些心得，與你分享。

2009 – 2013 年在北航讀本科，選了軟件工程這個專業(yè)。那個時候其實(shí)也不太清楚軟件工程和計算機(jī)有什么區(qū)別，大概軟件工程輕松比較多。本科的課程都差不多，C++、數(shù)據(jù)結(jié)構(gòu)、算法導(dǎo)論、計算機(jī)體系結(jié)構(gòu)、計算機(jī)網(wǎng)絡(luò)、操作系統(tǒng)原理、軟件工程、職業(yè)生涯規(guī)劃。畢業(yè)時正好趕上移動互聯(lián)網(wǎng)和萬眾創(chuàng)業(yè)的浪潮，抱著改變世界一點(diǎn)點(diǎn)的想法，成為了一名的產(chǎn)品經(jīng)理。

近幾年工作中的不設(shè)邊界，讓我有機(jī)會接觸了很多不同的知識體系。從產(chǎn)品、設(shè)計、運(yùn)營到客戶端、前端、后端、運(yùn)維、架構(gòu)再到管理、業(yè)務(wù)、投資，也有機(jī)會負(fù)責(zé)完整的產(chǎn)研團(tuán)隊。業(yè)務(wù)覆蓋了 2C、2D、2B、2G 多個方向，包括數(shù)字城市、物聯(lián)網(wǎng)平臺、SCRM平臺、海淘電商、商品導(dǎo)購、輕博客多個領(lǐng)域產(chǎn)品。

負(fù)責(zé)中后臺產(chǎn)品相關(guān)工作中漸漸對軟件工程、架構(gòu)設(shè)計有了越來越多的理解，同時也補(bǔ)充學(xué)習(xí)了包括微服務(wù)架構(gòu)、中臺體系、領(lǐng)域驅(qū)動設(shè)計等技術(shù)知識體系。本文整理了過往產(chǎn)品架構(gòu)設(shè)計中的一些心得，希望可以為大家提供一些有價值的內(nèi)容作為參考。

參考學(xué)習(xí)資料：

關(guān)于產(chǎn)品：

• 徐峰：《有效需求分析》
• 產(chǎn)品經(jīng)理認(rèn)證（NPDP）知識體系指南

關(guān)于設(shè)計：

• 設(shè)計工具：Ant Design + Kitchen + Sketch + 語雀
• Ant Design 設(shè)計工程化
• 設(shè)計原則->設(shè)備模式->設(shè)計資產(chǎn)
• 四表一局：圖表、表單、列表、表格和布局
• 知識圖譜：AntV 圖譜可視化設(shè)計
• 阿里云 CADT 云架構(gòu)設(shè)計工具 https://bpstudio.console.aliyun.com/

關(guān)于技術(shù)：

• 右軍、李偉山 、 張洪亮、彭首長、劉朋：《程序員的三門課》
• 斯坦福 John Ousterhout 教授：《軟件設(shè)計的哲學(xué)》常柱中文版譯文
• 李運(yùn)華：《從零開始學(xué)架構(gòu)》
• 王啟軍：《持續(xù)演進(jìn)的Cloud Native：云原生架構(gòu)下微服務(wù)最佳實(shí)踐》
• 覃宇：軟件架構(gòu)編年史(譯)

關(guān)于 DDD 領(lǐng)域驅(qū)動設(shè)計：

• 張建飛：《代碼精進(jìn)之路：從碼農(nóng)到工匠》
• 張逸：構(gòu)建領(lǐng)域驅(qū)動設(shè)計知識體系
• 歐創(chuàng)新：深度解析DDD中臺和微服務(wù)設(shè)計
• 歐創(chuàng)新、鄧頔：《中臺架構(gòu)與實(shí)現(xiàn)：基于 DDD 和微服務(wù)》
• 有贊湯師爺：有贊零售中臺建設(shè)方法的探索與實(shí)踐

關(guān)于數(shù)據(jù)中臺：

郭憶：數(shù)據(jù)中臺實(shí)戰(zhàn)課

本文將按照業(yè)務(wù)認(rèn)知、軟件工程、架構(gòu)設(shè)計、領(lǐng)域驅(qū)動設(shè)計、中臺體系、參考產(chǎn)品方案等依次展開，內(nèi)容側(cè)重在于骨干知識體系梳理，細(xì)節(jié)知識可以閱讀推薦的參考資料。

一、關(guān)于業(yè)務(wù)認(rèn)知

1. 業(yè)務(wù)是所有一切的根源

業(yè)務(wù)、產(chǎn)品、設(shè)計、技術(shù)是構(gòu)建產(chǎn)品的四個核心元素。當(dāng)我們想要做一個產(chǎn)品時，出發(fā)點(diǎn)都是為了解決一些問題。業(yè)務(wù)定義了問題是什么，產(chǎn)品定義了提供的解決方案，設(shè)計與技術(shù)支撐解決方案的實(shí)現(xiàn)。在我們的產(chǎn)研團(tuán)隊中也存在著業(yè)務(wù)負(fù)責(zé)人、產(chǎn)品經(jīng)理、設(shè)計師、工程師與之對應(yīng)。從上下游關(guān)系來看，產(chǎn)品的設(shè)計依賴于業(yè)務(wù)，而設(shè)計、技術(shù)的設(shè)計又依賴于產(chǎn)品。因此業(yè)務(wù)的變動是推動產(chǎn)品變動的核心因素，良好的產(chǎn)品架構(gòu)應(yīng)能快速響應(yīng)業(yè)務(wù)的變動。

2. 知識是從業(yè)務(wù)到產(chǎn)品的關(guān)鍵

當(dāng)我們要做一個電商平臺產(chǎn)品時，需要了解電商業(yè)務(wù)體系，包括選品、采購、倉庫、營銷、訂單、物流、售后等一系列業(yè)務(wù)板塊。我們想要把某一塊業(yè)務(wù)做好，需要團(tuán)隊有對應(yīng)領(lǐng)域的相關(guān)知識。

知識的學(xué)習(xí)途徑有很多，閱讀書籍與文章、研究行業(yè)競品、請教業(yè)務(wù)專家等等。研究行業(yè)競品直觀高效，而請教業(yè)務(wù)專家可以避免彎路。但從知識的結(jié)構(gòu)化程度來說，作為出版物的書籍是系統(tǒng)學(xué)習(xí)更好的選擇，它可以帶給你完整的知識體系。隨著近些年互聯(lián)網(wǎng)行業(yè)的成熟，各類垂直業(yè)務(wù)的書籍也越來越豐富，大大降低知識獲取的門檻。

3. 知識積累是抽象到具體的過程

大家應(yīng)該都有用過思維導(dǎo)圖類的工具，知識的描述是從抽象到具體的。我們認(rèn)知一個業(yè)務(wù)領(lǐng)域都是從主干開始，再到對應(yīng)的枝杈模塊，最后才是葉子細(xì)節(jié)。從小到大我們學(xué)過大量的知識，而在今天你很難對每個細(xì)節(jié)都記憶猶新，整個知識體系就像一個脈絡(luò)地圖，我們只記得枝干和重點(diǎn)的細(xì)節(jié)。當(dāng)需要了解某個特定細(xì)節(jié)時，由于對枝干有清晰的認(rèn)知，可以快速找到相應(yīng)的細(xì)節(jié)信息。

4. 業(yè)務(wù)的知識散布在各個環(huán)節(jié)

當(dāng)我們?nèi)プ瞿骋粔K業(yè)務(wù)時，不論什么崗位，都希望招到有相關(guān)業(yè)務(wù)工作經(jīng)驗(yàn)的候選人。業(yè)務(wù)的領(lǐng)域知識會影響相關(guān)的運(yùn)營知識、產(chǎn)品知識、技術(shù)知識、設(shè)計知識。例如電商平臺的產(chǎn)品與社交平臺的運(yùn)營方法不同、產(chǎn)品存在巨大差異，技術(shù)挑戰(zhàn)也不一樣，設(shè)計上也有很多風(fēng)格和細(xì)節(jié)的差異。

5. 知識的分拆與職能的分工

業(yè)務(wù)相關(guān)的知識是海量的，我們沒有辦法讓團(tuán)隊所有人都掌握全部的知識。改進(jìn)的方案有兩個方向，一是通過知識庫實(shí)現(xiàn)團(tuán)隊內(nèi)知識共享，提高每個人所掌握的知識范圍；二是通過職能分工的細(xì)拆降低每個人完成工作所需的知識量，也就是降低認(rèn)知負(fù)荷。

當(dāng)我們以橫向：業(yè)務(wù)、產(chǎn)品、設(shè)計、技術(shù)，縱向：架構(gòu)、模塊、細(xì)節(jié)來將知識體系去做拆解，可以得到下面一張表格。

縱向看每條職能線的知識體系會與相應(yīng)的崗位映射，以技術(shù)線為例，團(tuán)隊通常有架構(gòu)師、技術(shù)經(jīng)理、工程師多級崗位。從擁有知識的多少和內(nèi)容來看架構(gòu)師掌握宏觀框架性的知識和重點(diǎn)的功能細(xì)節(jié)知識，而負(fù)責(zé)某個具體功能的工程師掌握該全部的細(xì)節(jié)知識，這樣的分工使得每個人都專注在其工作相關(guān)的知識上。

橫向看每個知識層次的各職能崗位間有很多的協(xié)同，業(yè)務(wù)、產(chǎn)品、設(shè)計、技術(shù)跨職能的知識體系碰撞融合是產(chǎn)品深化的關(guān)鍵，相同的業(yè)務(wù)領(lǐng)域知識背景也讓溝通交流更順暢。

6. 內(nèi)聚知識的功能特性團(tuán)隊

我們常見的團(tuán)隊組織模式是職能型的，產(chǎn)品經(jīng)理輸出產(chǎn)品方案進(jìn)行組內(nèi)評審，再流轉(zhuǎn)給下一個環(huán)境的設(shè)計團(tuán)隊，最后在流轉(zhuǎn)給工程師團(tuán)隊。這種模式會面臨幾個顯著的問題，一是各團(tuán)隊負(fù)責(zé)人會接收大量的知識細(xì)節(jié)成為瓶頸點(diǎn)，二是由于缺乏跨職能部門的知識共享交流容易出現(xiàn)認(rèn)知偏差，三是由于某個功能模塊相應(yīng)的人員配合關(guān)系不穩(wěn)定，導(dǎo)致知識彌散在團(tuán)隊中，幾個人都知道一部分但又都不完整。

若我們按照功能特性式來進(jìn)行虛擬團(tuán)隊劃分，每個團(tuán)隊成員對負(fù)責(zé)的業(yè)務(wù)板塊有差不多的業(yè)務(wù)認(rèn)知，更有利于業(yè)務(wù)的推進(jìn)和深化。在業(yè)務(wù)可拆分進(jìn)行持續(xù)迭代的情況下，按照功能特性劃分團(tuán)隊推進(jìn)業(yè)務(wù)，職能線跟蹤人員管理和專業(yè)培養(yǎng)，是大型團(tuán)隊管理比較好實(shí)踐方案。

小結(jié)：

進(jìn)行產(chǎn)品架構(gòu)與功能設(shè)計，本質(zhì)是業(yè)務(wù)知識學(xué)習(xí)和表達(dá)轉(zhuǎn)換的過程，在通過軟件研發(fā)將方案進(jìn)行編碼實(shí)現(xiàn)。在軟件工程領(lǐng)域有 問題域 和 解決方案域 的概念，明確了問題域，才能做出滿足需求的產(chǎn)品。了解相關(guān)知識體系才能正確定義問題，同時設(shè)計出匹配的解決方案。

二、關(guān)于軟件工程

1. 軟件工程的起源

20 世紀(jì) 60 年代由于計算機(jī)技術(shù)的飛速發(fā)展，軟件系統(tǒng)的規(guī)模越來越大，復(fù)雜程度也越來越高。而早期的軟件開發(fā)者大多是以充滿了黑客精神的個人為主，在面對大型軟件項目時需要大團(tuán)隊協(xié)作就出現(xiàn)了多問題，導(dǎo)致項目交付頻繁延期，問題頻出。這就是所謂的 軟件危機(jī)，為了解決問題在 1968、1969 年連續(xù)召開兩次著名的NATO會議，并同時提出軟件工程的概念。

2. 軟件工程的發(fā)展過程

1）大爆炸模型

早期的軟件開發(fā)由于是以個人或小團(tuán)隊開發(fā)者為主，經(jīng)常采用 Code&Fix 的模式或者團(tuán)隊封閉一段時間突然出現(xiàn)一個令人驚喜的結(jié)果，好的或者壞的，這種模式也被稱為大爆炸模式。

2）瀑布模型

軟件工程從其他工程學(xué)例如土木建筑中吸取了很多經(jīng)驗(yàn)，人類已經(jīng)可以造成出非常宏偉的建筑，管理極其復(fù)雜的功能，通過早期盡可能詳盡設(shè)計，來避免后續(xù)工程施工過程中問題。隨著軟件研發(fā)的工程化出現(xiàn)了瀑布模型，完成前一項工作在進(jìn)行后一項工作，如果前項工作完成的沒有問題，那么后面就會很順利。

3）改進(jìn)瀑布模型

我們很難一開始將設(shè)計都做的特別正確，所以會出現(xiàn)到了下一個環(huán)節(jié)發(fā)現(xiàn)需要對上一個環(huán)節(jié)進(jìn)行修正，于是對瀑布模型做了改進(jìn)，允許下一個環(huán)節(jié)的反饋來修正前一個環(huán)節(jié)。

4）快速原型模型

但現(xiàn)實(shí)往往是殘酷的，除了設(shè)計缺陷外還經(jīng)常遇到項目到了測試環(huán)節(jié)，才發(fā)現(xiàn)做的一些東西并不符合客戶的預(yù)期，導(dǎo)致大量的資源浪費(fèi)。于是在前面又增加了原型環(huán)節(jié)，用低成本來驗(yàn)證所做的東西是不是符合客戶的預(yù)期。

5）增量與迭代

瀑布式的研發(fā)方式，雖然利用了工程化的方式改善了軟件研發(fā)過程，但沒有解決一個問題就是需求的變動。

通過增量與迭代兩種方法，可以降低需求變動帶來的影響。增量是將功能進(jìn)行拆分，先實(shí)現(xiàn)其中一部分，分批交付。迭代是將功能先進(jìn)行簡單的實(shí)現(xiàn)，實(shí)現(xiàn)快速交付。參考二八原則，系統(tǒng)內(nèi)大部分功能的使用頻次是很低的，可以將資源盡可能優(yōu)先用在高頻的功能研發(fā)上。

6）精益與敏捷

敏捷 與 精益 這兩者很相近，要說差異大概在于精益的核心是避免浪費(fèi)，敏捷的核心是快速響應(yīng)。涉及知識體系較大，詳細(xì)內(nèi)容就不在此處贅述了。

3. 核心理論與定律

1）蓋爾定律

“一個切實(shí)可行的復(fù)雜系統(tǒng)勢必是從一個切實(shí)可行的簡單系統(tǒng)發(fā)展而來的。從頭開始設(shè)計的復(fù)雜系統(tǒng)根本不切實(shí)可行，無法修修補(bǔ)補(bǔ)讓它切實(shí)可行。你必須由一個切實(shí)可行的簡單系統(tǒng)重新開始?！?/p>

這與產(chǎn)品構(gòu)建 MVP 策略是相同的，我們很難一開始掌握全局和所有細(xì)節(jié)，一上來就做很宏大的設(shè)計會付出慘重的代價，我們要做的第一步是先讓東西 run 起來。好的架構(gòu)設(shè)計可以讓我們再后面的完善過程中不會推倒重來，這種思路也叫漸進(jìn)式設(shè)計。雖然保持了持續(xù)交付價值，但是每一代產(chǎn)品基本都推倒重來，在做大型業(yè)務(wù)時要避免這樣的方案。

2）沒有銀彈

這篇是一篇經(jīng)典的論文《沒有銀彈：軟件工程的本質(zhì)性與附屬性工作》，文中提出的核心觀點(diǎn)： “所有軟件創(chuàng)作都包括了本質(zhì)性工作和附屬性工作，本質(zhì)性工作：即如何從抽象性問題，發(fā)展出具體概念上的解決方案；附屬性工作：將概念上的構(gòu)思施行于電腦上，所遭遇到的困難。軟件工程面臨的問題在于我們即使清除了大部分的次要復(fù)雜度，而剩余的主要本質(zhì)性工作帶來的復(fù)雜度都無法改變。”

即業(yè)務(wù)本身帶來的復(fù)雜度是無法改變，無論我們用什么樣的語言、框架、工程管理方法。但其實(shí)在今天業(yè)務(wù)帶來的本質(zhì)性工作的復(fù)雜度是可以降低，例如電商業(yè)務(wù)的很多業(yè)務(wù)板塊都已經(jīng)非常成熟，我們可以采用一些通用的業(yè)務(wù)方案，這樣可以縮小我們需要關(guān)注的業(yè)務(wù)的范圍，以此來降低復(fù)雜性。如今的熱點(diǎn)的中臺體系，通過業(yè)務(wù)能力復(fù)用，實(shí)現(xiàn)了本質(zhì)性工作的減少。

了解 DDD 領(lǐng)域驅(qū)動設(shè)計，可以將業(yè)務(wù)域可以劃分為核心域、支撐域、通用域三類，我們的資源重點(diǎn)投入在核心域上，支撐域、通用域的部分內(nèi)容可以考慮外采標(biāo)準(zhǔn)系統(tǒng)和找第三方定制開發(fā)來解決。

3）復(fù)雜性守恒定律

“每個應(yīng)用程序都具有其內(nèi)在的、無法簡化的復(fù)雜度。無論在產(chǎn)品開發(fā)環(huán)節(jié)還是在用戶與產(chǎn)品的交互環(huán)節(jié)，這一固有的復(fù)雜度都無法依照我們的意愿去除，只能設(shè)法調(diào)整、平衡?！?/p>

很多的中后臺系統(tǒng)中很多表單會存在大量的配置項，這些配置項是否可以簡化，讓平臺變得更簡單智能？大部分時候答案都是否定的，過度追求簡化往往容易弄巧成拙。功能邏輯易于解釋與理解才是更好的方案，當(dāng)你試圖簡化降低復(fù)雜度，可能在其他地方埋了雷。

4）人月神話

隨著人員的增加，團(tuán)隊內(nèi)溝通成本會呈指數(shù)增長。 公式：溝通成本 = n(n-1)/2。

• 5人項目組，需要溝通的渠道是 5*(5–1)/2 = 10
• 15人項目組，需要溝通的渠道是15*(15–1)/2 = 105
• 50人項目組，需要溝通的渠道是50*(50–1)/2 = 1,225
• 150人項目組，需要溝通的渠道是150*(150–1)/2 = 11,175

因此在軟件開發(fā)后期追加人員，由于溝通成本的上升，可能不會提速反而會更嚴(yán)重的延期。

任務(wù)根據(jù)特點(diǎn)可以拆接為 4 種類型，不同類型的 “人與月” 的曲線存在差異。

• 完全可以分解的任務(wù)，例如搬磚，加人就可以更快。
• 無法分解的任務(wù)，例如懷胎 10 月，加人不可能加速。
• 需要溝通的可分解任務(wù)，由于溝通成本引入了損耗。
• 關(guān)系錯綜復(fù)雜的任務(wù)，到一個階段后人越多越亂。

軟件研發(fā)屬于關(guān)系錯綜復(fù)雜的任務(wù)，沒辦法像搬磚一樣加人就提高效率。當(dāng)我們不斷的拆分任務(wù)與團(tuán)隊后，任務(wù)的復(fù)雜性會降低至需要溝通的可分解任務(wù)。

5）高內(nèi)聚低耦合

高內(nèi)聚低耦合是軟件設(shè)計的基本原則，大量的方法論都基于此衍生發(fā)展。假設(shè)將問題或者任務(wù)拆解成關(guān)聯(lián)比較弱的兩個部分，一個復(fù)雜的大問題就變成兩個沒那么復(fù)雜的問題，整體的復(fù)雜度就降低了。因此這一方法論是降低復(fù)雜度的關(guān)鍵方法，不僅適用于軟件設(shè)計，也適用于團(tuán)隊管理。

在業(yè)務(wù)認(rèn)知一節(jié)中有介紹通過對業(yè)務(wù)、知識的拆解，可以降低團(tuán)隊成員的認(rèn)知負(fù)荷。拆解結(jié)果符合業(yè)務(wù)子域內(nèi)的高內(nèi)聚，業(yè)務(wù)子域間的低耦合，就是好的拆解。功能特性團(tuán)隊在高內(nèi)聚的業(yè)務(wù)子域中具有更高的協(xié)作效率，團(tuán)隊間業(yè)務(wù)的低耦合降低溝通成本。

6）康威定律

“產(chǎn)品結(jié)構(gòu)反映了設(shè)計該產(chǎn)品的組織的溝通結(jié)構(gòu)”，團(tuán)隊的結(jié)構(gòu)影響會體現(xiàn)在產(chǎn)品上，組織架構(gòu)會影響業(yè)務(wù)、產(chǎn)品、技術(shù)、設(shè)計等多個方面。

業(yè)務(wù)架構(gòu)推導(dǎo)出產(chǎn)品架構(gòu)，產(chǎn)品架構(gòu)推導(dǎo)出技術(shù)架構(gòu)和數(shù)據(jù)架構(gòu)。 組織架構(gòu)會對一切造成影響，匹配的組織架構(gòu)是落地好業(yè)務(wù)架構(gòu)和技術(shù)架構(gòu)的重要因素。

小結(jié)：

軟件工程的本質(zhì)是管理復(fù)雜性，按照分而治之的思路高內(nèi)聚低耦合將業(yè)務(wù)、團(tuán)隊進(jìn)行拆解，降低團(tuán)隊成員完成任務(wù)的認(rèn)知負(fù)荷。部分業(yè)務(wù)模塊采用行業(yè)內(nèi)第三方標(biāo)準(zhǔn)方案，是降低復(fù)雜性的一種很好的途徑。《軟件設(shè)計的哲學(xué)》一書中提出復(fù)雜性來自于依賴和模糊的積累，好的設(shè)計最重要的目標(biāo)之一就是讓系統(tǒng)變得顯而易見。

若 A 依賴于 B，站在 A 的視角下對 B 的依賴越簡單越好，這樣負(fù)責(zé) A 的團(tuán)隊認(rèn)知負(fù)荷最低。由第三方提供的 B，通常會具備良好的設(shè)計文檔，例如我們加 Google Analytics 的 SDK 實(shí)現(xiàn)數(shù)據(jù)統(tǒng)計分析，我方不需要掌握其內(nèi)部的實(shí)現(xiàn)細(xì)節(jié)，只需要了解接口與產(chǎn)品使用，當(dāng)需要了解其內(nèi)部機(jī)制時可以查閱相關(guān)文檔。

軟件研發(fā)的發(fā)展是全行業(yè)的逐步沉淀過程，早期的數(shù)據(jù)分析需要自己搭建工具，再后來通過簡單埋點(diǎn)使用標(biāo)準(zhǔn)產(chǎn)品就能實(shí)現(xiàn)。整個過程是設(shè)計思路的共識 -> 技術(shù)方案的共識 -> 第三方標(biāo)準(zhǔn)產(chǎn)品，即統(tǒng)一思路降低理解難度，復(fù)用行業(yè)通用開源方案降低理解難度，使用第三方產(chǎn)品再大幅降低理解難度。

三、關(guān)于各種架構(gòu)

1. 架構(gòu)的定義

我們打開搜索引擎搜“架構(gòu)圖”，可以看到各式各樣五花八門的圖片。它們大致像下圖一樣，整張圖劃分了很多個小區(qū)域，每個小區(qū)域里有一些內(nèi)容，可能區(qū)域間箭頭線段聯(lián)系著。到底什么是架構(gòu)？參考百度百科：架構(gòu)就是對結(jié)構(gòu)和組件的描述，可以讓大家快速理解整個體系，指導(dǎo)一系列的細(xì)節(jié)設(shè)計。

2. 架構(gòu)的種類

我們經(jīng)常會聽到很多不一樣的名詞，方案架構(gòu)、業(yè)務(wù)架構(gòu)、應(yīng)用架構(gòu)、產(chǎn)品架構(gòu)、技術(shù)架構(gòu)、部署架構(gòu)、信息架構(gòu)。針對不同的視角維度，我們想要表達(dá)的結(jié)構(gòu)和組件是不同的，因此存在不同的架構(gòu)描述。

常見的一些架構(gòu)維度：

• 方案架構(gòu)，描述我們向客戶提供的東西是什么樣子的，怎么解決客戶對應(yīng)的問題。
• 業(yè)務(wù)架構(gòu)，描述我們要做一些什么樣的事情，對應(yīng)的業(yè)務(wù)流程和模式是怎樣的。
• 應(yīng)用架構(gòu)，描述我們提供哪些功能以及如何去實(shí)現(xiàn)這些功能，可拆解為產(chǎn)品架構(gòu)和技術(shù)架構(gòu)。
• 產(chǎn)品架構(gòu)，描述我們都實(shí)現(xiàn)了什么功能結(jié)構(gòu)，它們之間的關(guān)系是怎樣的。
• 信息架構(gòu)，描述我們產(chǎn)品的導(dǎo)航、功能是怎樣組織的，通常用思維導(dǎo)圖標(biāo)識。
• 技術(shù)架構(gòu)，描述我們的技術(shù)實(shí)現(xiàn)方案，例如微服務(wù)間的關(guān)系，中間件的使用，組件的設(shè)計等。
• 數(shù)據(jù)架構(gòu)，描述我們的數(shù)據(jù)邏輯模型、物理模型等。
• 部署架構(gòu)，描述我們的各種服務(wù)如何在環(huán)境中部署的。

3. 產(chǎn)品架構(gòu)設(shè)計

產(chǎn)品架構(gòu)設(shè)計從了解業(yè)務(wù)流程開始學(xué)習(xí)業(yè)務(wù)知識，再梳理拆解成若干的子問題域。理想的產(chǎn)品架構(gòu)設(shè)計方式是搭積木式的，例如我需要個商城系統(tǒng)就拼一個，需要個推薦系統(tǒng)再拼一個，需要個數(shù)據(jù)平臺就再來拼一個。這就需要我們具有比較廣闊的視野嗎，電商系統(tǒng)、推薦系統(tǒng)、積分系統(tǒng)、數(shù)據(jù)系統(tǒng)、反垃圾系統(tǒng)、風(fēng)控系統(tǒng)、內(nèi)容管理系統(tǒng)、計費(fèi)系統(tǒng)、工單系統(tǒng)、開發(fā)者系統(tǒng)、賬號權(quán)限系統(tǒng)等等…….

以賬號權(quán)限系統(tǒng)為例，賬號、用戶、組織、角色、權(quán)限、日志、審計、授權(quán)、單點(diǎn)登錄有很多知識內(nèi)容。電商系統(tǒng)中也有商品 SKU 管理、訂單拆單與快照、訂單狀態(tài)機(jī)、優(yōu)惠券與退單處理，還有如何設(shè)計訂單號這種技術(shù)分庫分表方案反向影響產(chǎn)品設(shè)計。

因此產(chǎn)品架構(gòu)設(shè)計，戰(zhàn)略部分來自對業(yè)務(wù)宏觀的理解，將各類能力進(jìn)行拼裝。戰(zhàn)術(shù)部分需要結(jié)合業(yè)務(wù)對各類子系統(tǒng)進(jìn)行設(shè)計改造以適應(yīng)現(xiàn)有的業(yè)務(wù)體系。不同的業(yè)務(wù)體量對產(chǎn)品方案有不同的需求，做一個小電商和淘寶、京東是不同的，小驢拉大車是拉不動了驢也累死了。即使我們采購了第三方非常完善的方案，團(tuán)隊去運(yùn)營使用也是有巨大成本的。

高內(nèi)聚低耦合就是先將板塊拆解清楚，每個子模塊都可以根據(jù)業(yè)務(wù)的發(fā)展情況進(jìn)行獨(dú)立迭代擴(kuò)展而不影響其他模塊，這樣才是解耦的優(yōu)秀架構(gòu)。

4. 技術(shù)架構(gòu)設(shè)計

產(chǎn)品架構(gòu)按照業(yè)務(wù)的天然特性進(jìn)行功能板塊拆解，通常情況下就是符合高內(nèi)聚低耦合的，因?yàn)橥粔K子業(yè)務(wù)必然是高內(nèi)聚的，業(yè)務(wù)模塊互相之間是低耦合的。但到了技術(shù)階段就是理想的狀態(tài)和殘酷的現(xiàn)實(shí)。

理想的狀態(tài)：

殘酷的現(xiàn)實(shí)：

技術(shù)架構(gòu)的發(fā)展從單體架構(gòu)大泥球到分層架構(gòu)，再到微服務(wù)架構(gòu)、事件驅(qū)動架構(gòu)、以及“萬物皆流”的流計算架構(gòu)。此處參考閱讀 覃宇：軟件架構(gòu)編年史(譯) 。

通過微服務(wù)架構(gòu)可以將原本的單體架構(gòu)進(jìn)行拆解，例如賬號微服務(wù)、訂單微服務(wù)、工單微服務(wù)等。微服務(wù)架構(gòu)有很多拆解設(shè)計的思路，此處參考閱讀 王啟軍：《持續(xù)演進(jìn)的Cloud Native：云原生架構(gòu)下微服務(wù)最佳實(shí)踐》

在微服務(wù)各類基礎(chǔ)設(shè)施日益成熟后，微服務(wù)相關(guān)的軟件研發(fā)附屬性問題被解決，但是在如何拆解這個業(yè)務(wù)本質(zhì)性問題出現(xiàn)了巨大的麻煩。不合理的微服務(wù)拆解，不僅不會降低復(fù)雜度，反而會制造出很大的麻煩。于是在 2019-2020 年，DDD 領(lǐng)域驅(qū)動設(shè)計開始熱了起來。

對于復(fù)雜的中后臺業(yè)務(wù)，通過面向領(lǐng)域的拆解可以與業(yè)務(wù)子域?qū)?yīng)，將業(yè)務(wù)、產(chǎn)品、技術(shù)的設(shè)計思路上統(tǒng)一，這樣業(yè)務(wù)引發(fā)產(chǎn)品需求變化，也會導(dǎo)致技術(shù)大規(guī)模的推倒重來。這也是 DDD 領(lǐng)域驅(qū)動設(shè)計戰(zhàn)略層的精髓。

技術(shù)架構(gòu)設(shè)計涉及的基礎(chǔ)技術(shù)知識建議閱讀：李運(yùn)華：《從零開始學(xué)架構(gòu)》

四、關(guān)于領(lǐng)域驅(qū)動設(shè)計

此處參考閱讀：

• 張建飛：《代碼精進(jìn)之路：從碼農(nóng)到工匠》
• 張逸：構(gòu)建領(lǐng)域驅(qū)動設(shè)計知識體系
• 歐創(chuàng)新：深度解析DDD中臺和微服務(wù)設(shè)計
• 歐創(chuàng)新、鄧頔：《中臺架構(gòu)與實(shí)現(xiàn)：基于 DDD 和微服務(wù)》
• 有贊湯師爺：有贊零售中臺建設(shè)方法的探索與實(shí)踐

DDD 領(lǐng)域驅(qū)動設(shè)計作為一個方法，分為戰(zhàn)略設(shè)計與戰(zhàn)術(shù)設(shè)計兩部分。戰(zhàn)略設(shè)計部分是業(yè)務(wù)、產(chǎn)品、技術(shù)相關(guān)的重點(diǎn)，戰(zhàn)術(shù)設(shè)計更多是研發(fā)實(shí)現(xiàn)。對于業(yè)務(wù)方來說，理解 DDD 是不必要的，業(yè)務(wù)方在團(tuán)隊中往往扮演著業(yè)務(wù)知識提供者的角色，業(yè)務(wù)模型的梳理還是依靠產(chǎn)品來完成。對于做中后臺產(chǎn)品的產(chǎn)品經(jīng)理和工程師來說了解 DDD 也不一定是必要的，但一定是有好處的。

1. DDD 領(lǐng)域驅(qū)動設(shè)計的核心知識點(diǎn)

• 統(tǒng)一業(yè)務(wù)語言
• 問題空間與解決方案空間
• 核心域、支撐域、通用域
• 四色建模法
• 事件風(fēng)暴
• 限界上下文、聚合根、實(shí)體、值對象
• 領(lǐng)域服務(wù)、領(lǐng)域事件、應(yīng)用服務(wù)、BFF 層
• 失血模型、貧血模型、充血模型、脹血模型
• CQRS 命令查詢分離與 Event Sourcing 事件溯源
• 事件消息設(shè)計的自洽與回查

2. 戰(zhàn)略設(shè)計

統(tǒng)一語言，做領(lǐng)域驅(qū)動設(shè)計第一步就是拉齊認(rèn)知，例如賬號、用戶到底指的是什么，有什么區(qū)別；電商系統(tǒng)的用戶和論壇中的用戶是不是一個用戶等等。這樣可以避免后續(xù)溝通時產(chǎn)生偏差。

問題空間與解決方案空間：

核心域、支撐域、通用域：

限界上下文與微服務(wù)拆解：

關(guān)于 DDD 領(lǐng)域驅(qū)動設(shè)計的知識不在此處贅述，閱讀推薦資料即可。

3. DDD、中臺、微服務(wù)間關(guān)系

摘自歐創(chuàng)新老師文章：中臺本質(zhì)是領(lǐng)域中的某一個子域，需要抽象并標(biāo)準(zhǔn)化，按照單一職責(zé)原則建立可復(fù)用的領(lǐng)域模型。而微服務(wù)則是中臺的最佳技術(shù)實(shí)現(xiàn)。DDD是一種可以同時指導(dǎo)中臺業(yè)務(wù)建模和微服務(wù)設(shè)計的方法論，它遵循高內(nèi)聚低耦合的原則，完成從業(yè)務(wù)端領(lǐng)域拆分、建模到應(yīng)用端微服務(wù)實(shí)現(xiàn)的無縫落地。

五、關(guān)于中臺體系

阿里的雙中臺體系為“業(yè)務(wù)中臺+數(shù)據(jù)中臺”，中臺的本質(zhì)是企業(yè)能力的復(fù)用，實(shí)現(xiàn)降本增效。

按照 DDD 領(lǐng)域驅(qū)動設(shè)計可以劃分出業(yè)務(wù)的核心域、支撐域、通用域，我們可以先將所有的中臺都理解為業(yè)務(wù)中臺，各種可復(fù)用的模塊被拆解未業(yè)務(wù)中臺中的 “XX中心”，例如賬號中心、設(shè)備中心、數(shù)據(jù)中心、工單中心等等。其中有些模塊因?yàn)槠渫ㄓ眯裕瑫猩虡I(yè)化的通用解決方案，可以被進(jìn)一步從內(nèi)部被拆離至外部。

常見的中臺：

• 業(yè)務(wù)中臺，與企業(yè)的業(yè)務(wù)高耦合，通常需要自己建設(shè)實(shí)現(xiàn)
• 數(shù)據(jù)中臺，工具型，中耦合，業(yè)務(wù)中臺與其他對接
• 技術(shù)中臺，工具型，低耦合，業(yè)務(wù)中臺與其他對接
• 身份中臺，工具型，中耦合，業(yè)務(wù)中臺與其他對接
• 低代碼中臺，工具型，中耦合，業(yè)務(wù)中臺與其他對接
• 物聯(lián)網(wǎng)中臺，工具型，中耦合，業(yè)務(wù)中臺與其他對接
• 視覺中臺，工具型，中耦合，業(yè)務(wù)中臺與其他對接
• 算法中臺，工具型，低耦合，業(yè)務(wù)中臺與其他對接

六、產(chǎn)品參考清單

行業(yè)標(biāo)準(zhǔn)產(chǎn)品參考：

身份中臺：

Authing https://authing.cn/

數(shù)據(jù)中臺：

• 袋鼠云 https://www.dtstack.com/
• 阿里云數(shù)據(jù)中臺 https://dp.alibaba.com/
• 網(wǎng)易易數(shù) https://www.163yun.com/product-bigdata
• 億信華辰 https://www.esensoft.com/

低代碼中臺：

• 簡道云 https://www.jiandaoyun.cn/
• 輕流 https://qingflow.com/
• 宜搭 https://www.aliwork.com/
• Mendix https://www.mendix.com/
• Outsystems https://www.outsystems.com/

物聯(lián)網(wǎng)中臺：

• 阿里云物聯(lián)網(wǎng)平臺 https://iot.aliyun.com/
• UCloud 物聯(lián)網(wǎng)平臺 https://www.ucloud.cn/site/product/uiot.html

視覺中臺：

• 螢石云 https://open.ys7.com/cn
• 阿里云視頻監(jiān)控 https://www.aliyun.com/product/vs

算法中臺：

• 阿里云視覺智能開放平臺 https://help.aliyun.com/document_detail/143096.html
• 火山引擎 https://www.volcengine.cn/product/imagerecognition

數(shù)據(jù)分析：

神策數(shù)據(jù) https://www.sensorsdata.cn/

效率工程平臺：

OnesAI https://ones.ai/

VR拍攝：

• Matterport https://matterport.com/
• Insta360 https://www.insta360.com/cn/enterprise/industries/real_estate
• 如視 https://realsee.com/

地球可視化：

• Mapbox 地圖引擎 https://www.mapbox.com/
• Cesium 地球 3D 可視化https://cesium.com/cesiumjs/
• Kepler 數(shù)據(jù)可視化引擎 https://kepler.gl/
• Google Earth https://www.google.com/earth/
• Airlook https://www.airlook.com/
• Maxar https://www.maxar.com/

七、企業(yè)級架構(gòu)探索

八、避免過度抽象

內(nèi)容回顧：

• 關(guān)于軟件工程
• 什么是軟件工程
• 大爆炸、瀑布、原型、增量、迭代
• RUP 統(tǒng)一軟件開發(fā)過程
• 精益與敏捷
• 人月神話
• 功能特性團(tuán)隊
• 軟件工程的本質(zhì)是管理復(fù)雜性
• 高內(nèi)聚，低耦合
• 康威定律
• 蓋爾定律
• 復(fù)雜性守恒定律
• 關(guān)于架構(gòu)
• 什么是架構(gòu)
• 架構(gòu)的種類與關(guān)系
• 業(yè)務(wù)、產(chǎn)品、技術(shù)、設(shè)計
• 組件化設(shè)計思維
• 演進(jìn)式架構(gòu)
• 關(guān)于領(lǐng)域驅(qū)動設(shè)計
• 統(tǒng)一業(yè)務(wù)語言
• 戰(zhàn)略設(shè)計與戰(zhàn)術(shù)設(shè)計
• 問題域與解決方案域
• 核心域、支撐域、通用域
• 限界上下文
• 領(lǐng)域模型，聚合、實(shí)體、值對象
• 領(lǐng)域服務(wù)、領(lǐng)域事件、應(yīng)用服務(wù)
• 關(guān)于中臺體系
• 大中臺，小前臺
• 雙中臺：業(yè)務(wù)中臺與數(shù)據(jù)中臺
• 關(guān)于企業(yè)級通用架構(gòu)
• 場景應(yīng)用
• 業(yè)務(wù)中臺
• 數(shù)據(jù)中臺
• 身份中臺
• 低代碼中臺
• 物聯(lián)網(wǎng)中臺
• 關(guān)于技術(shù)
• 分層架構(gòu)
• 微服務(wù)架構(gòu)
• 事件驅(qū)動架構(gòu)
• 流計算架構(gòu)
• SOLID 原則

本文由 @huiter 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自?Unsplash，基于 CC0 協(xié)議