中文字幕无线乱码人妻,老熟妇乱子伦系列视频

搜索

APP

起點課堂會員權益

職業體系課特權

線下行業大會特權

個人IP打造特權

30+門專項技能課

1300+專題課程

12場職場軟技能直播

12場求職輔導直播

12場專業技能直播

會員專屬社群

榮耀標識

發布

注冊 | 登錄

產品與技術架構指南

huiter

2021-04-07

7 評論 24164 瀏覽 321 收藏

39 分鐘

編輯導讀：產品經理在工作中會接觸很多前所未有的領域，學習到很多新知識。本文作者在負責中后臺產品相關工作中漸漸對軟件工程、架構設計有了越來越多的理解，同時也補充學習了包括微服務架構、中臺體系、領域驅動設計等技術知識體系。本文整理了過往產品架構設計中的一些心得，與你分享。

2009 – 2013 年在北航讀本科，選了軟件工程這個專業。那個時候其實也不太清楚軟件工程和計算機有什么區別，大概軟件工程輕松比較多。本科的課程都差不多，C++、數據結構、算法導論、計算機體系結構、計算機網絡、操作系統原理、軟件工程、職業生涯規劃。畢業時正好趕上移動互聯網和萬眾創業的浪潮，抱著改變世界一點點的想法，成為了一名的產品經理。

近幾年工作中的不設邊界，讓我有機會接觸了很多不同的知識體系。從產品、設計、運營到客戶端、前端、后端、運維、架構再到管理、業務、投資，也有機會負責完整的產研團隊。業務覆蓋了 2C、2D、2B、2G 多個方向，包括數字城市、物聯網平臺、SCRM平臺、海淘電商、商品導購、輕博客多個領域產品。

負責中后臺產品相關工作中漸漸對軟件工程、架構設計有了越來越多的理解，同時也補充學習了包括微服務架構、中臺體系、領域驅動設計等技術知識體系。本文整理了過往產品架構設計中的一些心得，希望可以為大家提供一些有價值的內容作為參考。

參考學習資料：

關于產品：

徐峰：《有效需求分析》
產品經理認證（NPDP）知識體系指南

關于設計：

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

關于技術：

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

關于 DDD 領域驅動設計：

張建飛：《代碼精進之路：從碼農到工匠》
張逸：構建領域驅動設計知識體系
歐創新：深度解析DDD中臺和微服務設計
歐創新、鄧頔：《中臺架構與實現：基于 DDD 和微服務》
有贊湯師爺：有贊零售中臺建設方法的探索與實踐

關于數據中臺：

郭憶：數據中臺實戰課

本文將按照業務認知、軟件工程、架構設計、領域驅動設計、中臺體系、參考產品方案等依次展開，內容側重在于骨干知識體系梳理，細節知識可以閱讀推薦的參考資料。

一、關于業務認知

1. 業務是所有一切的根源

業務、產品、設計、技術是構建產品的四個核心元素。當我們想要做一個產品時，出發點都是為了解決一些問題。業務定義了問題是什么，產品定義了提供的解決方案，設計與技術支撐解決方案的實現。在我們的產研團隊中也存在著業務負責人、產品經理、設計師、工程師與之對應。從上下游關系來看，產品的設計依賴于業務，而設計、技術的設計又依賴于產品。因此業務的變動是推動產品變動的核心因素，良好的產品架構應能快速響應業務的變動。

2. 知識是從業務到產品的關鍵

當我們要做一個電商平臺產品時，需要了解電商業務體系，包括選品、采購、倉庫、營銷、訂單、物流、售后等一系列業務板塊。我們想要把某一塊業務做好，需要團隊有對應領域的相關知識。

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

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

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

4. 業務的知識散布在各個環節

當我們去做某一塊業務時，不論什么崗位，都希望招到有相關業務工作經驗的候選人。業務的領域知識會影響相關的運營知識、產品知識、技術知識、設計知識。例如電商平臺的產品與社交平臺的運營方法不同、產品存在巨大差異，技術挑戰也不一樣，設計上也有很多風格和細節的差異。

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

業務相關的知識是海量的，我們沒有辦法讓團隊所有人都掌握全部的知識。改進的方案有兩個方向，一是通過知識庫實現團隊內知識共享，提高每個人所掌握的知識范圍；二是通過職能分工的細拆降低每個人完成工作所需的知識量，也就是降低認知負荷。

當我們以橫向：業務、產品、設計、技術，縱向：架構、模塊、細節來將知識體系去做拆解，可以得到下面一張表格。

縱向看每條職能線的知識體系會與相應的崗位映射，以技術線為例，團隊通常有架構師、技術經理、工程師多級崗位。從擁有知識的多少和內容來看架構師掌握宏觀框架性的知識和重點的功能細節知識，而負責某個具體功能的工程師掌握該全部的細節知識，這樣的分工使得每個人都專注在其工作相關的知識上。

橫向看每個知識層次的各職能崗位間有很多的協同，業務、產品、設計、技術跨職能的知識體系碰撞融合是產品深化的關鍵，相同的業務領域知識背景也讓溝通交流更順暢。

6. 內聚知識的功能特性團隊

我們常見的團隊組織模式是職能型的，產品經理輸出產品方案進行組內評審，再流轉給下一個環境的設計團隊，最后在流轉給工程師團隊。這種模式會面臨幾個顯著的問題，一是各團隊負責人會接收大量的知識細節成為瓶頸點，二是由于缺乏跨職能部門的知識共享交流容易出現認知偏差，三是由于某個功能模塊相應的人員配合關系不穩定，導致知識彌散在團隊中，幾個人都知道一部分但又都不完整。

若我們按照功能特性式來進行虛擬團隊劃分，每個團隊成員對負責的業務板塊有差不多的業務認知，更有利于業務的推進和深化。在業務可拆分進行持續迭代的情況下，按照功能特性劃分團隊推進業務，職能線跟蹤人員管理和專業培養，是大型團隊管理比較好實踐方案。

小結：

進行產品架構與功能設計，本質是業務知識學習和表達轉換的過程，在通過軟件研發將方案進行編碼實現。在軟件工程領域有問題域和解決方案域的概念，明確了問題域，才能做出滿足需求的產品。了解相關知識體系才能正確定義問題，同時設計出匹配的解決方案。

二、關于軟件工程

1. 軟件工程的起源

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

2. 軟件工程的發展過程

1）大爆炸模型

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

2）瀑布模型

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

3）改進瀑布模型

我們很難一開始將設計都做的特別正確，所以會出現到了下一個環節發現需要對上一個環節進行修正，于是對瀑布模型做了改進，允許下一個環節的反饋來修正前一個環節。

4）快速原型模型

但現實往往是殘酷的，除了設計缺陷外還經常遇到項目到了測試環節，才發現做的一些東西并不符合客戶的預期，導致大量的資源浪費。于是在前面又增加了原型環節，用低成本來驗證所做的東西是不是符合客戶的預期。

5）增量與迭代

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

通過增量與迭代兩種方法，可以降低需求變動帶來的影響。增量是將功能進行拆分，先實現其中一部分，分批交付。迭代是將功能先進行簡單的實現，實現快速交付。參考二八原則，系統內大部分功能的使用頻次是很低的，可以將資源盡可能優先用在高頻的功能研發上。

6）精益與敏捷

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

3. 核心理論與定律

1）蓋爾定律

“一個切實可行的復雜系統勢必是從一個切實可行的簡單系統發展而來的。從頭開始設計的復雜系統根本不切實可行，無法修修補補讓它切實可行。你必須由一個切實可行的簡單系統重新開始?！?/p>

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

2）沒有銀彈

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

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

了解 DDD 領域驅動設計，可以將業務域可以劃分為核心域、支撐域、通用域三類，我們的資源重點投入在核心域上，支撐域、通用域的部分內容可以考慮外采標準系統和找第三方定制開發來解決。

3）復雜性守恒定律

“每個應用程序都具有其內在的、無法簡化的復雜度。無論在產品開發環節還是在用戶與產品的交互環節，這一固有的復雜度都無法依照我們的意愿去除，只能設法調整、平衡。”

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

4）人月神話

隨著人員的增加，團隊內溝通成本會呈指數增長。公式：溝通成本 = 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

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

任務根據特點可以拆接為 4 種類型，不同類型的 “人與月” 的曲線存在差異。

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

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

5）高內聚低耦合

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

在業務認知一節中有介紹通過對業務、知識的拆解，可以降低團隊成員的認知負荷。拆解結果符合業務子域內的高內聚，業務子域間的低耦合，就是好的拆解。功能特性團隊在高內聚的業務子域中具有更高的協作效率，團隊間業務的低耦合降低溝通成本。

6）康威定律

“產品結構反映了設計該產品的組織的溝通結構”，團隊的結構影響會體現在產品上，組織架構會影響業務、產品、技術、設計等多個方面。

業務架構推導出產品架構，產品架構推導出技術架構和數據架構。組織架構會對一切造成影響，匹配的組織架構是落地好業務架構和技術架構的重要因素。

小結：

軟件工程的本質是管理復雜性，按照分而治之的思路高內聚低耦合將業務、團隊進行拆解，降低團隊成員完成任務的認知負荷。部分業務模塊采用行業內第三方標準方案，是降低復雜性的一種很好的途徑?！盾浖O計的哲學》一書中提出復雜性來自于依賴和模糊的積累，好的設計最重要的目標之一就是讓系統變得顯而易見。

若 A 依賴于 B，站在 A 的視角下對 B 的依賴越簡單越好，這樣負責 A 的團隊認知負荷最低。由第三方提供的 B，通常會具備良好的設計文檔，例如我們加 Google Analytics 的 SDK 實現數據統計分析，我方不需要掌握其內部的實現細節，只需要了解接口與產品使用，當需要了解其內部機制時可以查閱相關文檔。

軟件研發的發展是全行業的逐步沉淀過程，早期的數據分析需要自己搭建工具，再后來通過簡單埋點使用標準產品就能實現。整個過程是設計思路的共識 -> 技術方案的共識 -> 第三方標準產品，即統一思路降低理解難度，復用行業通用開源方案降低理解難度，使用第三方產品再大幅降低理解難度。

三、關于各種架構

1. 架構的定義

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

2. 架構的種類

我們經常會聽到很多不一樣的名詞，方案架構、業務架構、應用架構、產品架構、技術架構、部署架構、信息架構。針對不同的視角維度，我們想要表達的結構和組件是不同的，因此存在不同的架構描述。

常見的一些架構維度：

方案架構，描述我們向客戶提供的東西是什么樣子的，怎么解決客戶對應的問題。
業務架構，描述我們要做一些什么樣的事情，對應的業務流程和模式是怎樣的。
應用架構，描述我們提供哪些功能以及如何去實現這些功能，可拆解為產品架構和技術架構。
產品架構，描述我們都實現了什么功能結構，它們之間的關系是怎樣的。
信息架構，描述我們產品的導航、功能是怎樣組織的，通常用思維導圖標識。
技術架構，描述我們的技術實現方案，例如微服務間的關系，中間件的使用，組件的設計等。
數據架構，描述我們的數據邏輯模型、物理模型等。
部署架構，描述我們的各種服務如何在環境中部署的。

3. 產品架構設計

產品架構設計從了解業務流程開始學習業務知識，再梳理拆解成若干的子問題域。理想的產品架構設計方式是搭積木式的，例如我需要個商城系統就拼一個，需要個推薦系統再拼一個，需要個數據平臺就再來拼一個。這就需要我們具有比較廣闊的視野嗎，電商系統、推薦系統、積分系統、數據系統、反垃圾系統、風控系統、內容管理系統、計費系統、工單系統、開發者系統、賬號權限系統等等…….

以賬號權限系統為例，賬號、用戶、組織、角色、權限、日志、審計、授權、單點登錄有很多知識內容。電商系統中也有商品 SKU 管理、訂單拆單與快照、訂單狀態機、優惠券與退單處理，還有如何設計訂單號這種技術分庫分表方案反向影響產品設計。

因此產品架構設計，戰略部分來自對業務宏觀的理解，將各類能力進行拼裝。戰術部分需要結合業務對各類子系統進行設計改造以適應現有的業務體系。不同的業務體量對產品方案有不同的需求，做一個小電商和淘寶、京東是不同的，小驢拉大車是拉不動了驢也累死了。即使我們采購了第三方非常完善的方案，團隊去運營使用也是有巨大成本的。

高內聚低耦合就是先將板塊拆解清楚，每個子模塊都可以根據業務的發展情況進行獨立迭代擴展而不影響其他模塊，這樣才是解耦的優秀架構。

4. 技術架構設計

產品架構按照業務的天然特性進行功能板塊拆解，通常情況下就是符合高內聚低耦合的，因為同一塊子業務必然是高內聚的，業務模塊互相之間是低耦合的。但到了技術階段就是理想的狀態和殘酷的現實。

理想的狀態：

殘酷的現實：

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

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

在微服務各類基礎設施日益成熟后，微服務相關的軟件研發附屬性問題被解決，但是在如何拆解這個業務本質性問題出現了巨大的麻煩。不合理的微服務拆解，不僅不會降低復雜度，反而會制造出很大的麻煩。于是在 2019-2020 年，DDD 領域驅動設計開始熱了起來。

對于復雜的中后臺業務，通過面向領域的拆解可以與業務子域對應，將業務、產品、技術的設計思路上統一，這樣業務引發產品需求變化，也會導致技術大規模的推倒重來。這也是 DDD 領域驅動設計戰略層的精髓。

技術架構設計涉及的基礎技術知識建議閱讀：李運華：《從零開始學架構》

四、關于領域驅動設計

此處參考閱讀：

張建飛：《代碼精進之路：從碼農到工匠》
張逸：構建領域驅動設計知識體系
歐創新：深度解析DDD中臺和微服務設計
歐創新、鄧頔：《中臺架構與實現：基于 DDD 和微服務》
有贊湯師爺：有贊零售中臺建設方法的探索與實踐

DDD 領域驅動設計作為一個方法，分為戰略設計與戰術設計兩部分。戰略設計部分是業務、產品、技術相關的重點，戰術設計更多是研發實現。對于業務方來說，理解 DDD 是不必要的，業務方在團隊中往往扮演著業務知識提供者的角色，業務模型的梳理還是依靠產品來完成。對于做中后臺產品的產品經理和工程師來說了解 DDD 也不一定是必要的，但一定是有好處的。