大多數業務軟體系統都符合如圖的結構和公式 y = f(x)：

• 有一個請求 x，得到輸出 y
• 軟體系統即 f，f 根據 x 輸出 y
• 軟體系統的資料庫構造部分，有流水表，配置表。
• 流水表是隨著請求數量增減的
• 軟體根據配置表配置處理請求。
• 實際的軟體中，還會存在另外一種資料庫表：實體表，實體表是軟體處理請求時需要的數據，業務邏輯可能隨著實體表部分邏輯而有變化。

對於大多數企業級系統而言，多數業務都是可重現的。故若流水表定義為 y 撇（y 的一個可逆變換）, 則必有函數 fy 存在使得 y = fy(y 撇)。我們認為 y 和 y 撇在信息容量上是等價的（或者說在集合上是等價的）。

很顯然，流水表包含了所有的業務要素。簡單證明如下：

如果業務請求 x，則 x 包含所有業務要素。且業務請求 x 數量是無限集合 X。軟體 f 和配置表皆是有限集。若業務系統有持久化，業務可重現。則業務要素必然只能存儲於流水表，且流水表必然包含所有業務要素。

對於任何一個業務系統，我們得到結論或者推論：

• 推論 1，流水表包含此業務系統的所有業務要素
• 推論 2，用戶界面也包含了所有業務要素
• 推論 3，業務要素和系統的模塊化之間是可以映射的 // 自行證明
• 推論 4，此流水表業務要素是此類業務領域模型的一個子集

以上四個推論對數據系統的設計工作是有極大幫助的，它們將改變我們傳統的設計模式四大要求和業務軟體的矛盾。

我們知道我們不可能讓業務去學技術，而只能讓技術去學業務。但是學習成本非常高，時間消耗非常大，學習邊界和效果不好衡量。通過推論 1 和推論 2，使得技術人員對業務的學習和掌握變的更有目的和邊界。

我們都說系統是演變過來的，而不是設計出來的。這句話一無是處，又極具欺騙性——任何事情都有過程，好的系統有，爛的系統也有，好的系統的過程自然不能否定這句話，可是我沒見過哪個爛系統因為這句話變好過的。這句話在現實中有兩種場景會出現：

• 事前架構設計實在無用且浪費時間，以此節約時間
• 自己負責的系統太壞被人指責，來招乾坤大挪移

它的唯一有益的是逃避了設計工作——設計對業務開發沒什麼實質幫助（這是普遍情況）———為業務開發爭取了足夠的時間，加快業務響應效率。但是在有了可行的設計方法，能夠解決設計和業務新系統矛盾的情況下。正確的做法既不應該逃避事前設計的，也不應該逃避時候責任。推論 123 是幫助我們事前快速設計系統的方法，推論 4 是幫助整體架構演進的基本依據。

通過以上四個推論（業務的數據要素模型），結合業務流程圖，基本上可以在短短几分鐘到幾個小時內完成需求的設計，並且這種設計是過去和現在情況下的最優解。將使設計工作變的可落地，客觀。通過以上四個推論，可以在一天或者幾天之內梳理完一個遺留系統的全部業務，給出最優設計方案，當前問題和改進辦法。不單單是基於用戶 UI 或者遺留系統，對新建系統和需求呢？它同樣是有效的，我們只需要多做幾個點：

• 關注的是 PRD（產品文檔）到業務要素映射，這是閱讀文檔的重點。
• 注意 PRD 有可能是不完備的，不可行的；還可能是有冗餘的，要思考分辨。

我們在過去較長時間在大量系統中實踐過和推廣過這些辦法，效果是非常驚人的。對於遺留系統基本上能在幾天和一周之內分析清楚並給出改造意見，對於新系統，領域設計和開發速度、後續業務支持能力、響應速度和風險效果都非常好。開發人員也反饋成長很快。

?

同時要注意的是，這種方法是針對數據系統的特殊結構取巧的一個解法。並不一定普適於非數據系統。譬如，對於中間件系統，CAD 類系統，或者風控系統等，它依賴於數據系統結構，依賴於流水表，依賴於可重現。

通過這些辦法，我們利用數據系統的一些特徵，去掉了傳統設計方法中過於模糊、不可操作和落地，成本高昂的部分。讓業務系統真的變得可設計，讓設計真正變得可落地。

系統劃分辦法

大多數業務系統都屬於數據系統，都可以按照上文中的模型去設計和處理。但是我們必須提醒：雖然我們上文一直討論的是流水系統模型，但是一個流水表，就是一個系統么？流水數據模型某種層面只是幫助我們抓住業務要素的一個辦法，並不是劃分系統的依據。

系統劃分的合理依據是流水表之間的耦合性和內聚性，以及整體業務的複雜度。

在抽象層面，所有的流水表都可以抽象為一個表。通過 type 來區分就可以了。但是 type 和 type 之間的關係數量，以及業務系統的代碼複雜度會急劇上升。也可以一個流水表一個系統，這個系統的複雜度會非常低，但因為流水表之間有耦合內聚性，這導致這個系統和其他系統有較強的依賴關係，會導致整體的複雜度上升。這方法本質是把對象依賴轉變為系統依賴，開發效率會極大降低，協作成本，通訊成本會極大提升。甚至有很多極端的一個 API 一個系統的，接近於走火入魔了。提到以上兩個辦法看起來是啰啰嗦嗦，錯誤很低級，似乎正常人都不會犯，似乎提這些是非常沒有必要。可是近年來隨著工匠精神的崛起，過於強調技術，為技術而技術，導致這些看起來非常低級的錯誤都大量湧現，甚至廣為傳播，大加宣揚。

還經常有技術人員有類似的想法——我們可以發明一個業務系統，能解決所有的業務問題。我們可以發明一個系統，能解決所有的業務問題。或者我們應該拆分的更細一點，更微服務一點，更 SOA 一點，對象單一職責嘛，越簡單越好。要我說，一個系統能解決所有的業務這種東西已經有了，但是大家都不滿意，比如 Object，比如 Interface，它什麼都是，但你沒滿意。

你不能做出讓所有人都滿意都系統，因為存在「複雜度」這個因素。你越抽象，客戶化要做的就越多，差異化要做的就越多，你那裡少做了，這裡就必須補回來，因為業務目標的業務複雜度是恆定的，不可減少的。設計上少做了，抽象了，業務上就多做了，繁瑣了。細節上簡單，少做了，簡單了，總體上就複雜了，多做了。這是一個從系統設計到對象級編碼都會大量犯的錯——沒有意識到軟體設計和複雜度的關係。

為所有的複雜度要素劃分最合理的領域，尋求最優化的展現形式，尋求最合理的分工是系統劃分的目標。傳統上，內聚性較高的流水表之間封閉為一個系統是一種很好的辦法，但並非最優辦法。這也是很多創業公司最實際的做法——就一個系統，無論用戶系統，還是業務系統，都在裡面。因為這幾個領域雖然彼此耦合性不高，但是也並不足夠複雜。這種形式成本最低，也適合初創期精簡的團隊。即使在很多大型公司，也常常見到很多彼此領域無關的幾個業務做在一個系統中，比如將省份數據、圖片管理等統一封裝到一個 common 項目。這幾個領域毫無任何關聯關係，這是形式成本最低和分工決定的。

我看到有大量公司，有大量程序員，盲目效法別人的成功做法，或者知名大公司的做法，盲目跟風業界潮流，沒有正確的軟體架構觀，不能思辨的吸收，導致系統腐化，僵化的並不鮮見。毛主席說這是教條主義。

在我看來，在不違反耦合性和內聚性的前提下，總是選擇成本最低，總複雜度最低的方案。對不同的企業，雖然有部分業務是相同的，但是並沒有一層不變的系統劃分標準，未必需要按照其他企業的標準劃分，還是要具體情況具體分析。多數情況為了省事，可以拷貝，但是這不意味著是最合理的。

?

以我多年的系統重構經驗，大多數看起來非常複雜的業務系統經過抽象以後其實都非常簡單，完全沒有進行細粒度拆分的必要性。合併是一個更合理的選擇。合併比拆分好，合併會導致總複雜度降低，運行成本降低。

但是合併有一個上限。一個系統的總體複雜度不能超過 owner 它的團隊的可控制複雜度的能力上限，我認為還是要保持一定 buffer 比較好——也許 1/2，也許 2/3。

?

簡單總結一下：

• 拆分的依據是內聚耦合性
• 拆分的缺陷是複雜性增加、效率降低
• 合併比拆分好。
• 單體系統複雜度不能超過團隊可控制的上限（的 n/m，n<m）

模塊形態

軟體是由模塊組成的，模塊應該是什麼樣子的？依模塊和軟體的關係，所有可能的形態有 6 種：

• 代碼行
• 函數
• 類 / 介面
• 本地模塊 (本地內聚較強的代碼集合，即模塊一詞的原意)
• SOA(遠端內聚較強的代碼集合，作為系統的組成的一部分)
• 介於本地模塊和 SOA 之間（即傳統意義上的 RichClient，以及最近流行的微服務）

這 6 種形態的特點如下：

模式 6 有兩種形態：RichClient 和微服務（我個人覺得這兩種沒區別，更多是一個營銷噱頭，故合併為 6）。RichClient 是一個廣為大家熟知的概念，它往往意味著一個 SOA 的 Client 並非一個純粹的介面或者沒有任何多少業務邏輯的類，而是有較多邏輯的。這些邏輯往往和業務系統耦合性較低，但和 SOA 端耦合較高——這種模塊結構能簡化業務系統開發的複雜度。模式 6 的另外一種形態在 Spring 四大神器中得到淋漓盡致的體現——Richclient 的伺服器端往往提供的是數據，本地模塊是數據執行環境——四大神器的數據不是來自於伺服器端，而是來自於業務系統本身。devtools 通過感知 class 變化提供了熱載入能力；autoconfiguration 感知業務系統組件，提供動態組件創建服務；actuator 獲知系統運行情況，提供系統運行服務——這些同樣是業務邏輯所不關心的，能大大簡化業務系統開發的。

我並不認為模塊的數據來自哪裡是這兩種模式的本質特徵，我認為和業務系統的職能分工是它們的本質的和真正價值所在。如果將來再出現一種模式，部分數據是來自本地，部分數據是來自 SOA 我們該如何區分呢？那些認為 Springboot 是微服務 Dubbo 不是微服務的，Restful 就是微服務 RPC 就不是微服務，在 Dubbo 僅僅寫幾個擴展類改成 Restful 以後，springboot 通過 foeign 封裝為，該如何分辨呢？微服務 /Richclient 的核心價值就是簡化複雜業務系統。在使用中，在滿足業務要求的前提下選擇最優的模塊形態。

以某大型互聯網公司加解密系統為例，其業務核心要和大量不同機構對接，有大量加解密需求，架構演進如下：

• 核心系統直接引入第三方加解密演算法，第三方加解密 jar 包，隨著結構對接數量增加和複雜性增加，jar 包衝突，系統複雜度上升，難以維護，系統不穩定性提升。
• 採用 SOA 方式，設計一個獨立的加解密系統，向業務系統屏蔽第三方 jar，管理各種機構、介面和演算法之間的映射、審批、版本……
• SOA 方式 IO 消耗過高——一般系統瓶頸都是 IO，極少是 CPU，為了加解密進行一次或者多次 IO 傳輸有撿了芝麻丟了西瓜之嫌的意思——更好的做法是兼有本地的性能和遠端的功能；需要一個 RichClient 能動態載入並解析運行演算法。

一般而言，在性能、可用性等要求滿足的情況下，我同時會考慮複雜度最低的形態。能用 api 解決不會用一個類，能用一個類解決的不會用一個模塊，能用一個模塊解決的不會用 SOA、微服務。能不開發的，就不開發。

在模塊實現形式上，我同樣發現有很多錯誤的方式 :

1. 用高成本的方式去做成本的事情，追求過度設計。
2. 過於強調模式 5、6 的可控性，隔離性。卻忽視它的本質是變化的正交的通用部分，而並非變化本身。

譬如有些公司公司將高度變化的業務系統劃分成多個獨立的模塊，每個部分都是按照某種理論或大師的說法或知名公司的最佳實踐等來設計的，理論上和其他部分可以保持很好的隔離性。但實際情況是來一個業務需求 N 個業務新系統一起變化，並且修改的代價是系統級的，聯調是 N 個系統級的。本來很簡單的事情，做的非常複雜；本來完整的概念，切割的支離破碎，無人可以掌控。

要解決這個問題，我建議的做法進行業務的概念模型設計，將所有的變化都抽象為概念的某些擴展或者屬性的變化。為開發人員構建一個完整的業務概念和業務變化視圖，給出全局觀。在系統實現上區分不變的引擎部分和變化的客戶化部分。從這個角度去理解模塊選擇，而不是基於技術或者理念本身。

因為模塊的本質不過是整體和局部的關係，並且同樣模塊要關注耦合和內聚性。從這個本質去理解模塊的設計就要求我們必須如此，從業務出發，從整體出發，從業務模型入手，模塊形式只是這個理念的一個具體技術落實手段，並非關鍵，沉迷於此，不可能得到最優最合理的解決方案。

DDD 和代碼角色

通過系統劃分、模塊拆分將複雜度分而治之，但不可能做到簡化複雜度。拆分同時會導致問題碎片化、理解和綜合困難增加、協調成本提升、複雜性增加，飲鴆止渴當適可而止的。取捨和抽象是效果更好的辦法。取捨能避免關注次要問題，降低複雜度；抽象能做到簡化複雜度、提升內聚性、靈活性、可擴展性、做到形散而神不散。

DDD 是一個包含了抽象和設計方法論的方法。·網路上能搜索到的對 DDD 的研究可以分為三個層次：

1. 關於問題域本身的概念層面的抽象和設計的方法論
2. 關於代碼角色和層次結構的方法論
3. 關於 CQRS、EDA 等具體技術框架層次或者思想的

這三塊並非一個有機的整體。層次 1 研究問題域的抽象、內聚性和劃分問題和組合結構，是 DDD 的核心內容。層次 2 研究代碼本身的角色和組織方式，是 DDD 理論在代碼書寫形式上的應用和最佳實踐，它抽象了任何軟體的組成部分和構造關係，研究更合理優雅的設計。層次 3 是部分問題域情況下的最佳實踐，並非普適的；不加區分的去使用往往是有害的。

在層次 2 中，一般我會比較認為六邊形理論更普適更合理但對人的要求較高，它更能適應現實世界的概念之間毫無層次但是彼此耦合的情況。層次模型更簡單易用但不普適於問題，但對人的要求較低，適合做大規模項目的管理方法的延伸。

在代碼的角色劃分上，我個人理解和書中所寫也略有偏差。對於數據系統，我認為有這幾個角色就夠了——介面層、邏輯對象、值對象、實體對象、基礎設施層。結合數據系統模型你就會發現：

• 介面層：系統介面
• 邏輯對象：系統中的業務邏輯
• 值對象：系統中的配置對象和配置表
• 實體對象：系統中的 xy 或流水表|實體表
• 基礎設施層：系統中除業務邏輯和配置對象外的東西

有很多人反映聚合根很難理解，結合數據系統模型和下圖，你就會發現很簡單。聚合根就是實體對象（實體對象也可以再找出一個或者幾個聚合根）。

從業務邏輯的角度來看，業務邏輯可以寫在邏輯對象中，也可以寫在值對象（即配置對象—業務或者產品配置等），還可以寫在實體對象中；如果業務邏輯寫在實體對象和配置對象中，就稱為充血模型；如果全部寫在業務邏輯對象中，則配置對象和實體對象退化成貧血模型。

判定業務邏輯適合寫在業務邏輯對象中還是值對象 / 實體對象的依據就是和這些對象的內聚性關係。並且業務邏輯對象和配置對象的邊界是模糊的，如果你將變化表現為配置，它就是配置對象；如果你將它寫成業務邏輯，它就是邏輯對象。他們真正不可逾越的邊界是業務邏輯對象可以和基礎設施層發生依賴，可以和任意對象發生依賴，而值對象不可以和基礎設施層和介面層發生依賴。另外如果值對象和實體對象有一個充血方法，放在兩者中皆可，我們建議放在值對象中。實體對象也和值對象是同樣的情況——至少在 Java 中我們推薦這麼做，在一些動態性更強的語言比如 Ruby 中，實體對象可以輕易做到使用基礎設施能力透明的提供更加友好的充血方法，這樣做更好。

• 業務邏輯和值對象之間是邊界模糊的。
• 值對象即配置表的 runtime 實例
• 充血模型值對象 + 配置表決定了一個系統的擴展能力和靈活性。

關於層次 3，只是特定場景下的最佳解決方案。DDD 的精髓並不在這裡；很多 DDD 擁躉喜歡用這裡的某些理念去實施 DDD，常常沒有較好的結果，根本原因就是過重，削足適履。

時刻要牢記：軟體工程的最大問題是複雜性，DDD 是幫我們解決複雜性的。如果 DDD 帶來複雜性則不用 DDD，如果某種方案帶來複雜性則不用某種方案，他們都是工具。

系統到模塊的分解

系統整體上可以分為 2 個模塊部分：

• 上圖紅線部分，稱為業務模塊：實現的是整塊業務邏輯 y = f(x)
• 邏輯片段 x 部分：因為業務邏輯是可 retry 的，實現不同事件觸發的子邏輯模塊。
• 邏輯片段部分是由很多具體功能模塊實現的。

分辨流水對象，可以對應整體業務邏輯對象。通過分析業務流程圖，或者看流水表的狀態欄位，可以了解邏輯片段數量。通過閱讀產品需求或者代碼，可以了解全部的業務邏輯。基於不同業務邏輯 片段的共性分析，可以抽取公有模塊。通過對公有模塊性質的分析，選取最合適的模塊形態。可以最大化減少開發成本，提升設計質量，運行穩定性。

業務系統中間件化架構

傳統上一般將軟體分為三類：居於最底層的操作系統，居於最上層的業務軟體和介於其間的中間件。如果我們按照需求頻率、開發周期和系統腐化程度（掉坑係數，戲稱，即陷入研發焦油坑的可能性）去看的話，會有如下一個表格：

那麼，在中間件和應用軟體之間是否可以存在一層稱為業務中間件層的東西，它可能既有中間件的較高的軟體質量，較低的掉坑係數，又兼有業務軟體快速響應業務、開發周期短的優點呢？

如果我們將傳統的業務軟體分為業務軟體引擎 + 業務配置兩個部分，在業務配置不用關注業務通用性和複雜性，耦合性，自然就可以有較低的業務響應成本，就可以在總投入不變的情況下，將這些收益轉入到個更好的業務軟體引擎投入部分，從而做到更好設計、通用性、軟體質量。但是層級多了同樣會增加組織架構和協作的複雜性，所以如無必要，勿增實體。

?

以金融 IT 行業為例。最初金融 IT 是掌握在一些行業專業公司手中。銀行的科技部門是一個能力較弱的支撐部門，對系統的掌控能力是非常弱的，對業務的支撐也是較弱的。乙方具有較強的業務建模和開發能力，軟體具有較高的通用性，但不會考慮太多過於複雜和靈活的客戶化需求。

隨著互聯網的發展，市場上產生了充裕的 IT 人員，這既導致市場上更多的行業公司出現，也導致銀行的科技部門壯大，科技部門和行業公司共同滿足業務部門靈活而多變的需求。

近些年來，隨著銀行、互聯網公司技術投入日漸增加，科技能力溢出越來越明顯，IT 投入成本壓力也越來越大。已經出現很多銀行將內部的研發中心獨立成科技公司，很多互聯網公司也在尋求科技能力輸出。這種發展趨勢的結果會導致行業軟體重新變得更加通用化。但不同於之前，這些通用化的行業解決方案同時具有非常靈活的擴展能力、較低的客戶化成本、快速的業務響應能力。

(胖客戶端 / 瘦客戶端發展歷程)

金融 IT 的這種發展歷程像極了胖瘦客戶端發展的歷程。最初是胖而不靈活的 CS 模式，然後發展成了靈活的 BS 模式；最初的 BS 客戶端能力是非常弱的，最終變得非常強大非常類似 CS，同時兼具 BS 的靈活性。

金融 IT 行業也發展的好像回去了，但是本質已經完全不同了。

不單單是金融，所以行業軟體格局的這種發展都應該會符合這個規律，變成如下的樣子：

在不遠的將來，行業解決方案軟體公司可能將重新興起，業務軟體將不像現在這樣是需求的堆積，而是高度模型化、設計化的產物。

架構原則：三離四化

三離四化是：

• 業務和技術分離
• 業務和部署分離
• 變與不變分離
• 參數化，腳本化，流程化，引擎化

為什麼要業務和技術分離，業務和部署分離？

答案：風險、成本、靈活性。

我們之前的文章里談到了很多技術選擇的風險，這本質是人的風險。系統肯定是團隊合作的產物，也一定不是一個個足夠理性的人，技術決策風險是不可避免的。一方面，我們需要規避這種風險。如果業務層和技術層隔離了，我們既能避免這種業務風險，又能鼓勵技術人員技術創新。

在內容上，如果我們剝離了技術、部署的部分，理論上業務內核只是一個純粹的業務 DSL，體積是最小的，開發成本是最低的，靈活性是最高的。

當然純粹的業務 DSL 只是一個原則，這只是一個理想狀態，完全屏蔽技術本身就是一種不切實際的思想，也沒有多少實際意義，我不必需要的的業務核心可以隨意的在 Java 和 Python 之間實現之間透明切換。在選取最大技術公約數的情況下，我們可以著重的關注一些高頻的真正有意義的變化。這樣能最大化降低我們的成本。

人與人，與組織機構之間的一些問題同樣會影響軟體工程，並且它的影響可能要遠遠大於技術，這是組織域和組織熵，裡面可能涉及到一些技術型的解決方案，可能涉及到一些政治性的解決方案，這些非架構和技術仁和園可控的的東西就不詳細贅述了，但是必須明白和注意。

一個公司的核心技術框架一旦確定，變化的可能性不大，微觀的變化也是允許的。並不是一個特別大的問題。我們也同樣無需將我們的業務系統按照高度抽象的原則，設計的對任何變化透明——只需要對存在的變化的需求透明就可以了。有些理論上存在的變化但是實際上並不會發生，那就是不變的部分，可以寫死。只需要將變化的部分分離出來，做成可配置，可擴展的就好了。這是變與不變分離。

業務系統中間件化（引擎化）是即是不變的部分，客戶化（參數化，腳本化，流程化）即是變化的部分。這樣引擎的開發成本是最低的，需求的響應成本是最低的。系統的整體質量和穩定性是最高的，風險亦可控。

配置中心：業務系統和環境變化之間的配置存儲、同步的框架或者系統。

參數中心：維持業務系統業務概念，概念之間關係；以及業務配置和業務系統之間存儲、同步的的系統。如果做到了業務系統引擎化|領域化，參數中心即業務需求，即中台。對於大型分散式系統而言，一個統一而獨立的參數中心對於維持完整的業務概念、處理灰度、版本變化、同步等非業務型技術問題是非常有幫助的。不同於配置中心，它應該是可運行時 lazyload 的，業務相關而非環境相關的；它的數據結構、數據關係要複雜的多。

正交

這部分的內容本來應該出現在《系統到模塊的分解》這部分後面，來論述模塊之間的關係。但是又覺得不合適——不僅僅是模塊，而是大多數的東西之間的關係都應該服從這樣的關係。

正交是一個源自數學的基本概念，比如歐幾里得幾何 5 大公理是彼此正交的。他們的組合方式會產生無窮無盡的定理——能完美解釋任何空間結構。物理上時間，空間，動量，能量，他們彼此也是正交的……

正交需要抽象出一個體系的最原子的結構。

在一個完美的軟體體系中，也應該用正交的概念來構建。

軟體的基本概念就是：概念、概念之間的依賴、以及變化、不可知。

軟體工程的基本概念就是：軟體，技術，人，它們之間彼此的作用、以及變化。

任何一個領域也應該用正交的概念來構建。

DDD 的代碼角色理論：介面，邏輯 ，實體對象，值對象，基礎設施，事件對象。

交易領域：買家，賣家，商品，金額。

三離四化。

……

介面之間應該是正交的，對象之間應該是正交的，模塊之間應該是正交的……（本質上這幾個是一回事，對象是小的系統，模塊；系統、模塊是大的對象）。

正交單元是架構圖的基本單元，是領域模型的基本單元，是 ER 圖的基本單元，是屬性設計的基本單元。

業務系統中間件化的實踐經驗總結

我把上面這套理論叫做業務系統中間件化。

我在 14 年前後萌生了業務系統中間件化的基本想法。之前已經做了接近 10 年業務系統，中間也做過中間件，覺得中間件沒有挑戰就轉回業務系統線了。業務系統需求是一個高頻事件、中間件系統需求並非一個高頻事件。我喜歡解決能看到現實意義的，做能給團隊帶來效果的問題。

你能看到的大多數業務系統的質量都是極差的，沒人願意接手的，即使讓開發中間件過來的人來做業務系統也沒用 ，這本身說明業務系統設計是一個高難度的事情。但是能解決這個問題一定很酷。

之前研究過很多架構理論，但是大多數都是第一頁看不完就丟一邊了。因為我的偶像愛因斯坦也是這樣的，傳說別人拿新理論給他看，他往往瞄一眼就丟一邊，說：「太丑」。作為一個愛好數學、物理和哲學的外行，我的學術水平和素養雖然沒上去，但是欣賞水平和脾氣卻上去的非常厲害。我相信好的架構設計方法一定是簡單的，直達本質的。

尋找辦法的過程是很盲目的。就一直這麼兜兜轉轉。經過很多靈光乍現和試錯，然後就有了這些東西。最喜歡的事是：最後發現這些規律都太簡單了，太容易使用了。然後有 2 年左右的時間，一直在致力於這套理論的實踐。

實踐的效果，是比較驚人的，一般我能夠在一天或者幾天之內了解一個遺留系統，重構過的軟體代碼一般是原系統的 1/3~1/6 甚至更多，擴展性，穩定性極大提升，業務支持能力和響應效率提升數倍；開發時間縮短一半以上。團隊成員反映成長極快。但並非全部結果都令人滿意：有大約 50% 是結果很好，我完全滿意，有大約 50% 有各式各樣的問題，不能讓我滿意。能全部都好反而不正常，技術和設計不是 superman 能挽救一切。你大部分的時間，都不是在解決技術的問題，而是在解決人的問題、公司的問題……雖然我其他水平不行，沒有完全解決各種問題，但這已經是我現在能做到的了，我非常滿意這個結局。

所有過往，皆為序章。所有將來，皆是可盼。

推薦閱讀：