以(yǐ)往開發、測試、産品設計、項目管理的(de)工作經曆，對于(yú)架構工作來(lái)說(shuō)都是(shì)财富。而(ér)那些架構理論、模式及案例，就(jiù)好比一(yī / yì ／yí)顆顆珍珠，每顆都光彩奪目，但在(zài) 具體實踐過程中，似乎理論和(hé / huò)實踐無法很好地(dì / de)銜接，就(jiù)像缺少一(yī / yì ／yí)根串起珍珠的(de)線。本文梳理了(le／liǎo)平安科技首席應用架構師蔡學镛的(de)架構設計方法論，這(zhè)套方法論整合了(le／liǎo) 多種架構設計理論，能夠讓架構設計工作變得更加流暢和(hé / huò)高效。

　　在(zài)職業規劃中，程序“猿”會有多個(gè)進化方向：項目經理、産品經理、技術專家、架構師、售前經理等。不(bù)同的(de)選擇有不(bù)同的(de)憧憬，但也(yě)預示着不(bù)同的(de)挑戰。站在(zài)人(rén)生的(de)十字路口踯躅不(bù)前時(shí)，你的(de)腦海中是(shì)否曾掠過這(zhè)樣一(yī / yì ／yí)個(gè)念頭——沒的(de)選擇有時(shí)也(yě)是(shì)一(yī / yì ／yí)種幸福。

　　這(zhè)是(shì)我曾經曆過的(de)一(yī / yì ／yí)種狀态。缺什麽補什麽，網絡上(shàng)職業規劃相關的(de)信息就(jiù)會引起我的(de)注意。偶然的(de)機會，看到(dào)了(le／liǎo)蔡學镛老師這(zhè)方面的(de)坦誠分享。一(yī / yì ／yí)路走來(lái)， 有堅持，也(yě)有放棄，而(ér)這(zhè)些取舍的(de)背後就(jiù)是(shì)興趣，強化優勢，然後圍繞着興趣去突破自己，放棄彌補非緻命缺陷。在(zài)痛苦面前，人(rén)的(de)本能反應就(jiù)是(shì)退縮，懷疑之(zhī)前的(de) 選擇是(shì)否正确，一(yī / yì ／yí)旦開始懷疑就(jiù)會讓你停滞不(bù)前。如果是(shì)外物促使你選擇了(le／liǎo)某條路線，那你極有可能就(jiù)放棄了(le／liǎo)。而(ér)如果這(zhè)條路線是(shì)你的(de)興趣所在(zài)，那情況就(jiù)會完全不(bù) 同，它會讓你樂在(zài)其中，在(zài)遭受挫折之(zhī)後很快滿血，熱情投入，不(bù)斷突破自己。

　　古人(rén)雲：知之(zhī)者不(bù)如好之(zhī)者，好知者不(bù)如樂之(zhī)者。愛因斯坦曾說(shuō)：興趣，是(shì)最好的(de)老師。排除外部幹擾、傾聽内心，我選擇架構師作爲(wéi / wèi)我下一(yī / yì ／yí)個(gè)階段的(de)進化方向。

“高大(dà)上(shàng)”的(de)架構師之(zhī)路

　　當金融遇見互聯網會發生什麽？移動支付業務保持高位增長，10年内60%的(de)信用卡将會被移動支付取代，15年内90%中小金融機構的(de)前台将被取代。 移動化、智能化、雲計算和(hé / huò)大(dà)數據将成爲(wéi / wèi)主流，這(zhè)就(jiù)是(shì)颠覆式的(de)互聯網金融。變革的(de)時(shí)代，孕育着無限機遇，但同時(shí)也(yě)隐藏着巨大(dà)的(de)挑戰。相比于(yú)傳統的(de)企業級系 統，互聯網系統有着不(bù)同的(de)特點，如表1所示。

 

 

　　可見，架構工作對素質和(hé / huò)技能的(de)要(yào / yāo)求更“高”了(le／liǎo)，以(yǐ)往更多是(shì)做精做專，現在(zài)是(shì)要(yào / yāo)在(zài)精專基礎上(shàng)尋求廣博；要(yào / yāo)求具備更“大(dà)”的(de)眼界，不(bù)僅隻關注一(yī / yì ／yí)個(gè)階段的(de) 細節，而(ér)要(yào / yāo)關注整個(gè)産品生命周期；爲(wéi / wèi)輸出(chū)高質量的(de)架構設計，需要(yào / yāo)面對的(de)“上(shàng)”遊客戶更多了(le／liǎo)，還涉及各類幹系人(rén)及制度規則、商業環境、政策法規等。高、大(dà)、 上(shàng)，架構師之(zhī)路任重而(ér)道(dào)遠！

　　這(zhè)些年，我也(yě)讀了(le／liǎo)不(bù)少架構書籍，參加了(le／liǎo)一(yī / yì ／yí)些專業交流和(hé / huò)培訓。這(zhè)當中有介紹架構理論的(de)，有介紹架構模式的(de)，有分享架構案例的(de)，也(yě)有培訓分視圖做架構 的(de)。業界也(yě)出(chū)現很多新的(de)理論和(hé / huò)模式，其中有些非常經典，例如DDD、REST、SEDA等。而(ér)這(zhè)些理論、模式及案例，就(jiù)好比一(yī / yì ／yí)顆顆珍珠，每顆都光彩奪目， 但在(zài)實踐過程中，我覺得理論和(hé / huò)實踐無法很好的(de)銜接，就(jiù)像缺少一(yī / yì ／yí)根串起珍珠的(de)線。

　　俗話說(shuō)：讀萬卷書不(bù)如行萬裏路，行萬裏路不(bù)如閱人(rén)無數，閱人(rén)無數不(bù)如名師指路，名師指路不(bù)如自己開悟。閱讀經典、項目實踐、同行交流，短期内都不(bù)能 幫自己突破瓶頸，如果能夠得到(dào)名師的(de)指點，或許就(jiù)可以(yǐ)打通任督二脈。與往次不(bù)同的(de)是(shì)，這(zhè)次蔡老師是(shì)作爲(wéi / wèi)平安集團互聯網架構師、平安科技首席應用架構師的(de)身 份做架構設計方法論培訓。據個(gè)人(rén)了(le／liǎo)解，業界從規格到(dào)實現的(de)方法和(hé / huò)經驗分享非常多，但銜接需求和(hé / huò)規格的(de)可操作方法論比較少。而(ér)這(zhè)套方法論既整合了(le／liǎo)多種理論技 術，又具備很強的(de)可操作性。

蔡氏架構設計方法

　　針對問題域的(de)特點，這(zhè)套方法論采用與之(zhī)相對應的(de)多維度、立體化、分層次、動态演進的(de)策略，通過空間（X、Y、Z）三個(gè)維度及時(shí)間（T）維度将問題域 解構成可以(yǐ)輕松應對的(de)小方塊，分而(ér)治之(zhī)。同時(shí)，空間（X、Y、Z）三個(gè)維度聯動，專門爲(wéi / wèi)單個(gè)維度解決不(bù)了(le／liǎo)的(de)問題提供解決方案。時(shí)間（T）維度将問題分解到(dào) 一(yī / yì ／yí)個(gè)時(shí)間範圍内，分步驟按節奏逐一(yī / yì ／yí)解決，如圖1所示。接下來(lái)，讓我們進入這(zhè)個(gè)四維的(de)架構時(shí)空一(yī / yì ／yí)探究竟吧！

 

 

【四維座标系統】

1. 前後端維度（X1 … X7）

 

 

　　前後端維度被分解爲(wéi / wèi)交互、業務、領域、資源四大(dà)層，其中業務可以(yǐ)細分爲(wéi / wèi)應用X2、框架X3，領域可以(yǐ)細分爲(wéi / wèi)服務X4、核心X5，資源也(yě)可以(yǐ)細分爲(wéi / wèi)代 理X6、數據X7，共七個(gè)層次，如圖2所示。服務X4可以(yǐ)實現API，如果公開，就(jiù)是(shì)開放接口，調用服務層的(de)接口，通常需要(yào / yāo)授權。代理X6可以(yǐ)實現 SPI，隔離耦合，避免核心X5依賴特定的(de)外部系統或數據庫。每個(gè)層次做到(dào)高内聚，層與層之(zhī)間做到(dào)低耦合，詳見表2中的(de)X軸七層架構模型及定位所示。

 

 

　　在(zài)系統實現過程中，可以(yǐ)綜合考慮現狀，X2應用和(hé / huò)X3框架可以(yǐ)不(bù)分拆，X4服務和(hé / huò)X5核心可以(yǐ)不(bù)分拆，待後續時(shí)機成熟可以(yǐ)再重構分層，這(zhè)樣變更範圍僅在(zài)内部。

2. 業務維度（Y1 … Yn）

　　從業務維度進行劃分，按照業務類型對系統進行分類。業務系統的(de)劃分更多依賴業務領域的(de)知識。這(zhè)個(gè)維度的(de)設計方法，本文暫不(bù)深入介紹。

　　當Y軸的(de)一(yī / yì ／yí)個(gè)業務系統需要(yào / yāo)調用Y軸的(de)另外一(yī / yì ／yí)個(gè)業務系統時(shí)，兼顧效率和(hé / huò)耦合，這(zhè)套架構設計方法論給出(chū)了(le／liǎo)具體的(de)架構原則，如圖3所示。

 

 

（1）當被調用的(de)是(shì)公共系統時(shí)，那麽調用将被視爲(wéi / wèi)内部調用，即服務可以(yǐ)直接調用服務。考慮到(dào)公共系統比較穩定，不(bù)會經常改變，直接調用可以(yǐ)減少調用環節，保障效率。

（2）當被調用的(de)是(shì)非公共系統時(shí)，那麽調用将會被視爲(wéi / wèi)外部調用，即通過代理層去調用被調用系統的(de)對外服務接口。這(zhè)相當于(yú)把兩個(gè)系統後台進行了(le／liǎo)串聯，降低了(le／liǎo)系統之(zhī)間的(de)耦合，後續被調用系統發生變更，對調用系統的(de)影響也(yě)可以(yǐ)借由其代理層進行了(le／liǎo)隔離。

 

 

3. 系統維度（Z1 … Zn）

　　該維度主要(yào / yāo)關注軟件、容器、運行時(shí)、操作系統、虛拟機、硬件等這(zhè)些與業務無關系統的(de)架構。Z軸的(de)系統可以(yǐ)分别用于(yú)前端優化、應用優化、平台優化、資源優化等層面，如圖4所示。

4. 時(shí)間維度（T1 … Tn）

　　對于(yú)一(yī / yì ／yí)個(gè)新産品來(lái)說(shuō)，架構不(bù)是(shì)一(yī / yì ／yí)次成型的(de)，從初始到(dào)成熟要(yào / yāo)經過一(yī / yì ／yí)個(gè)不(bù)斷演進的(de)過程。對于(yú)一(yī / yì ／yí)個(gè)已有産品來(lái)說(shuō)，架構的(de)優化也(yě)是(shì)要(yào / yāo)結合實際情況分步驟實施。

　　除了(le／liǎo)技術上(shàng)的(de)考慮之(zhī)外，我們還需要(yào / yāo)考慮市場及投資等方面的(de)情況。通常在(zài)研發初期，産品本身的(de)定位還不(bù)太清晰，需要(yào / yāo)快速地(dì / de)叠代投放市場獲取先發優勢以(yǐ) 及驗證想法，不(bù)斷地(dì / de)明确産品的(de)定位。這(zhè)個(gè)階段産品需求變動非常頻繁，許多架構的(de)驅動因素尚未明确，如果過于(yú)關注架構，那産品推向市場就(jiù)會遙遙無期。随着産 品定位的(de)逐步清晰，架構的(de)驅動因素及約束條件都逐漸浮出(chū)水面，這(zhè)時(shí)架構設計的(de)重要(yào / yāo)性就(jiù)顯現出(chū)來(lái)了(le／liǎo)。另外，我們還需要(yào / yāo)根據投資預算來(lái)調整架構設計。如果投入 比較充裕，那我們就(jiù)可以(yǐ)投入更多的(de)人(rén)力來(lái)提前将架構驅動因素研究清楚，甚至可以(yǐ)針對不(bù)确定的(de)約束提供多套備選方案。

【X軸設計——架構設計流程】

　　如圖5的(de)架構設計流程圖所示。

　　第一(yī / yì ／yí)步，結合現實情況，将系統劃分成多個(gè)層次。

　　第二步，确定層與層之(zhī)間的(de)關系，梳理出(chū)層與層之(zhī)間的(de)交互接口。

　　第三步，将功能相近的(de)接口劃歸到(dào)一(yī / yì ／yí)個(gè)模塊，确保模塊高内聚，對外低耦合。

　　第四步，以(yǐ)上(shàng)面爲(wéi / wèi)基礎，進一(yī / yì ／yí)步明晰接口的(de)參數列表。

 

 

　　僅僅四個(gè)步驟就(jiù)完成了(le／liǎo)架構設計嗎？這(zhè)會不(bù)會太簡單空洞了(le／liǎo)呢？各位看官，不(bù)要(yào / yāo)着急，請聽蔡老師慢慢道(dào)來(lái)，每個(gè)步驟都有極具可操作性的(de)方法及工具。

1. 層次的(de)切分方法

　　面對一(yī / yì ／yí)個(gè)龐然大(dà)物，你該如何下手呢？不(bù)用擔心，這(zhè)已給你準備了(le／liǎo)庖丁解牛的(de)方法，輕輕松松把一(yī / yì ／yí)個(gè)複雜的(de)大(dà)系統變得可以(yǐ)掌控了(le／liǎo)。

　　第一(yī / yì ／yí)刀：按照這(zhè)套方法論來(lái)進行架構設計，最理想的(de)情況是(shì)将X軸切分成七層。而(ér)第一(yī / yì ／yí)刀應該先切在(zài)業務和(hé / huò)領域之(zhī)間，即通過API把兩邊解耦。交互和(hé / huò)業務跟用戶關聯度高，經常随需求變化而(ér)改動，而(ér)領域和(hé / huò)資源相對比較穩定。

　　第二刀：考慮到(dào)要(yào / yāo)完成某些業務功能，系統可能需要(yào / yāo)調用外部系統來(lái)協同完成，爲(wéi / wèi)了(le／liǎo)保證領域層相對穩定，我們需要(yào / yāo)隔離外部系統或數據持久層變化帶來(lái)的(de)影響，第二刀應該切在(zài)領域和(hé / huò)資源之(zhī)間。

　　第三刀：考慮到(dào)同樣的(de)一(yī / yì ／yí)個(gè)業務可能會有多套界面，例如有Web版、桌面版、移動版等，爲(wéi / wèi)了(le／liǎo)提高重用，隔離變更，接下來(lái)要(yào / yāo)把交互和(hé / huò)業務切開。

　　通過上(shàng)面這(zhè)“溫柔的(de)三刀”，我們就(jiù)可以(yǐ)把一(yī / yì ／yí)個(gè)大(dà)塊頭切分成七個(gè)層次。

2. 接口的(de)設計方法

　　在(zài)确定分層之(zhī)後，我們可以(yǐ)把每個(gè)業務需求的(de)交互時(shí)序圖畫出(chū)來(lái)，而(ér)分層就(jiù)是(shì)交互時(shí)序圖的(de)主角，如圖6所示，這(zhè)時(shí)我們就(jiù)可以(yǐ)清晰地(dì / de)找出(chū)層與層之(zhī)間的(de)交互接口，以(yǐ)及可以(yǐ)初步确定每個(gè)接口的(de)參數列表。

 

 

　　考慮到(dào)API、領域模型接口、SPI是(shì)最爲(wéi / wèi)關鍵的(de)接口，那良好的(de)設計就(jiù)顯得更爲(wéi / wèi)重要(yào / yāo)。如何能夠設計出(chū)良好的(de)接口？如圖7所示。

 

 

（1）找出(chū)領域對象：通過多輪領域訪談，與業務專家一(yī / yì ／yí)起分析出(chū)領域對象。另外，也(yě)可以(yǐ)通過研究外部接口及數據字典來(lái)明晰領域對象，反過來(lái)也(yě)可以(yǐ)豐富外部接口和(hé / huò)數據字典。

（2）設計領域模型、資源模型、數據模型：在(zài)挖掘領域對象的(de)過程中，我們就(jiù)可以(yǐ)開始設計領域模型了(le／liǎo)，确定領域對象之(zhī)間的(de)關聯關系。當關聯關系逐步清 晰之(zhī)後，我們還可以(yǐ)根據關聯關系的(de)密集程度對領域對象的(de)組織方式做一(yī / yì ／yí)些調整，找出(chū)核心的(de)領域對象集合，其他(tā)領域對象可以(yǐ)歸類到(dào)圍繞核心領域對象集合的(de)衛星 集合裏面。通過多輪調整，可以(yǐ)得到(dào)一(yī / yì ／yí)個(gè)能夠映射業務、關系簡化的(de)領域模型。然後兵分兩路啓動資源模型和(hé / huò)數據模型的(de)設計工作。上(shàng)述三個(gè)模型之(zhī)間的(de)關系及區 别，請參見下文。

（3）設計領域模型接口、API、SPI、數據庫：在(zài)設計領域模型接口時(shí)，要(yào / yāo)盡量做到(dào)不(bù)多不(bù)少，這(zhè)些接口都是(shì)對外提供服務所必需的(de)，也(yě)是(shì)全面的(de)，并 且粒度要(yào / yāo)細。在(zài)設計API時(shí)，要(yào / yāo)考慮内外客戶的(de)需求和(hé / huò)特點，做到(dào)方便易用，可以(yǐ)參考RESTful API設計相關的(de)資料。在(zài)設計SPI時(shí)，要(yào / yāo)盡量隔離資源層對領域層的(de)影響。

在(zài)完成上(shàng)述工作後，我們就(jiù)可以(yǐ)進入實施階段，開始啓動代理層、核心層和(hé / huò)服務層的(de)代碼設計工作。另外，如果是(shì)對線上(shàng)已有系統進行升級，那還要(yào / yāo)開始制訂數據的(de)遷移計劃。

3. 三個(gè)模型之(zhī)間的(de)關系及區别

　　領域模型，映射特定業務領域當中核心領域對象及其關聯關系，這(zhè)些對象及關系的(de)存在(zài)都是(shì)完成業務規則所必需的(de)，甚至是(shì)法律法規等明文要(yào / yāo)求的(de)，不(bù)會輕易變動。

　　資源模型，基于(yú)領域模型，從爲(wéi / wèi)内外客戶提供服務的(de)角度分析定義出(chū)來(lái)的(de)，包含了(le／liǎo)資源對象及其關聯關系。根據内外客戶的(de)特點及需求，我們可以(yǐ)調整資源模型中的(de)内容。

　　數據模型，基于(yú)領域模型，從存儲（持久化或緩存）信息的(de)角度分析定義出(chū)來(lái)的(de)，包含數據對象及其關聯關系。根據存儲載體的(de)特點及需求，我們可以(yǐ)調整數據模型中的(de)内容。

4. 接口類型的(de)分類方法

　　如何确定圖形用戶接口（GUI）和(hé / huò)應用編程接口（API）的(de)分工呢？如圖8所示，在(zài)收集業務需求的(de)過程中，我們可以(yǐ)标識出(chū)發起這(zhè)個(gè)需求的(de)角色是(shì)人(rén)還是(shì)程序。如果發起需求的(de)是(shì)人(rén)，那就(jiù)需要(yào / yāo)通過GUI來(lái)滿足；而(ér)如果發起需求的(de)是(shì)程序，那就(jiù)要(yào / yāo)通過API來(lái)滿足。

 

 

5. 模塊的(de)設計方法

　　架構設計流程第三步，按照功能相近的(de)原則将接口劃歸到(dào)不(bù)同的(de)模塊當中。劃分模塊就(jiù)會涉及業務拆分。如圖9所示，跟分層第一(yī / yì ／yí)刀位置一(yī / yì ／yí)樣，我們選擇業務 層和(hé / huò)領域層的(de)交界處來(lái)做業務拆分。業務拆分需要(yào / yāo)跟業務專家一(yī / yì ／yí)起來(lái)完成，通過這(zhè)個(gè)過程可以(yǐ)确定出(chū)Y軸包含哪些業務系統，而(ér)這(zhè)些業務系統的(de)公用模塊或系統将會 被劃分到(dào)業務層X2、領域層X4當中。

 

 

　　在(zài)做完第一(yī / yì ／yí)輪業務拆分之(zhī)後，就(jiù)可以(yǐ)進入設計階段，确定業務的(de)交互流程，進一(yī / yì ／yí)步明确業務層X2、領域層X4。然後并行啓動交互設計和(hé / huò)建模，其中交互設 計是(shì)爲(wéi / wèi)了(le／liǎo)确定交互層X1和(hé / huò)業務層X2，而(ér)建模是(shì)爲(wéi / wèi)了(le／liǎo)明确領域層X4、X5以(yǐ)及資源層X6。設計和(hé / huò)業務拆分可以(yǐ)叠代多次，直至可以(yǐ)進入下個(gè)階段——模塊設計 及數據存儲設計。

　　根據業務設計的(de)結果，我們可以(yǐ)進行模塊設計，明确X1到(dào)X6等層的(de)模塊組成。而(ér)建模的(de)結果可以(yǐ)用于(yú)數據存儲設計，明确X1、X3、X6、X7這(zhè)些層 次的(de)模塊劃分。模塊設計和(hé / huò)數據存儲設計可以(yǐ)互相推動。當上(shàng)述設計都完成之(zhī)後，就(jiù)可以(yǐ)進入網絡部署規劃，最後就(jiù)可以(yǐ)做人(rén)員機器規劃，進入實施階段。随着實施 深入，發現問題後及時(shí)重新叠代整個(gè)過程。

在(zài)實戰中踐行理論

　　誠如蔡老師所說(shuō)：幹貨甚幹，請配合開水服用！那我想這(zhè)開水就(jiù)是(shì)實踐吧。打鐵趁熱，我把正參與的(de)兩個(gè)項目作爲(wéi / wèi)實踐這(zhè)套方法論的(de)戰場。

　　這(zhè)兩個(gè)項目各有特點，在(zài)實踐過程中就(jiù)會有不(bù)同的(de)挑戰。其中，壹企業，是(shì)平安首個(gè)基于(yú)SaaS雲技術打造的(de)企業管理平台，滿足中小企業人(rén)事、财務、客 戶關系等管理需求，是(shì)一(yī / yì ／yí)個(gè)全新的(de)項目。而(ér)信用卡坐席系統二代是(shì)一(yī / yì ／yí)個(gè)升級項目，一(yī / yì ／yí)代系統已服役了(le／liǎo)很多年，累積了(le／liǎo)許多可以(yǐ)繼承的(de)子(zǐ)系統和(hé / huò)模塊。

　　壹企業的(de)系統架構如圖10所示，X軸切了(le／liǎo)兩刀半，這(zhè)樣資源、領域這(zhè)兩層就(jiù)形成了(le／liǎo)。資源層内部再細分爲(wéi / wèi)代理和(hé / huò)數據，其中代理負責數據訪問及調用外部系 統服務，并以(yǐ)SPI方式向領域層提供服務。領域層内部再細分爲(wéi / wèi)服務和(hé / huò)核心，其中核心就(jiù)是(shì)領域模型的(de)實現，而(ér)服務就(jiù)是(shì)資源模型的(de)實現，以(yǐ)API方式對外提 供，并計劃加入到(dào)開放平台（Open API）當中，服務于(yú)更多合作夥伴：第三方應用提供商。

 

 

　　信用卡坐席二代，這(zhè)是(shì)我們非常熟悉的(de)一(yī / yì ／yí)個(gè)業務領域，市場價值也(yě)是(shì)可以(yǐ)預期的(de)。基于(yú)上(shàng)述前提，信用卡坐席二代在(zài)X軸上(shàng)切分爲(wéi / wèi)交互、業務、領域、資源四 大(dà)層。其中，交互層就(jiù)是(shì)以(yǐ)界面爲(wéi / wèi)主；業務層暫不(bù)分應用和(hé / huò)框架，均統一(yī / yì ／yí)在(zài)應用裏面；領域層分爲(wéi / wèi)服務和(hé / huò)核心，其中服務将加入開放平台（Open API），核心就(jiù)由信用卡開放平台承擔；資源層分爲(wéi / wèi)代理和(hé / huò)數據，負責數據持久化，以(yǐ)及與信用卡業務相關的(de)外圍系統進行交互。

　　懂得很多道(dào)理，不(bù)一(yī / yì ／yí)定能過好這(zhè)一(yī / yì ／yí)生。而(ér)懂得這(zhè)套方法論，那架構設計就(jiù)可以(yǐ)做得更好！分享的(de)意義更多在(zài)于(yú)梳理自己認知，加深對這(zhè)套方法論的(de)理解。鑒于(yú)個(gè)人(rén)水平有限，文中一(yī / yì ／yí)定存在(zài)些許偏頗之(zhī)處，歡迎大(dà)家交流指正，一(yī / yì ／yí)起玩轉這(zhè)套蔡氏架構設計方法論。

　　文中許多想法來(lái)自嚴雲濤、孫國(guó)勇、江琳、曾荀、王剛、許揚、顔詩超、楊果林等小夥伴們的(de)分享與讨論，在(zài)此向大(dà)家表示感謝！

　　另外需要(yào / yāo)說(shuō)明的(de)是(shì)，文中部分插圖源自蔡學镛老師的(de)培訓教材《軟件架構入門》及書籍《編程ING》。

　　作者：徐勝勇