架構的 “一小步”，業務的一大步

摘要： 0 1 談到“架構”這兩個字，會有好多的名詞閃現，比如:分層架構、事件驅動架構、DDD、CQRS等。亦或者一堆的軟體設計原則，如：KISS原則（Keep it Simple and Stupid）、SOLID原則(單一責任原則、開放封閉原則、里氏替換原則、介面分離原則、依賴導致原則)等...

0 1

談到“架構”這兩個字，會有好多的名詞閃現，比如:分層架構、事件驅動架構、DDD、CQRS等。亦或者一堆的軟體設計原則，如：KISS原則（Keep it Simple and Stupid）、SOLID原則(單一責任原則、開放封閉原則、里氏替換原則、介面分離原則、依賴導致原則)等。甚至如狀態圖、用例圖、時序圖、活動圖等UML建模，GOF設計模式等。

本文不會討論這些架構概念，而是從閒魚詳情頁這個業務場景出發，分析出當前的業務問題和痛點，然後通過一步步的架構推導設計，解決這些痛點。隨著業務的發展，相信這些問題大家都會遇到。而解決問題的過程，或多或少的會用到上面的設計原則。

圖1 一種架構的定義

但隨著業務發展，人員不斷增加，老的架構難以支撐業務的發展，穩定性和效率受到極大挑戰。蠻荒時代已過，精耕細作的時代到來，急需一種更合適的架構來支撐業務的發展。

以閒魚的詳情頁舉例，在業務初期，詳情的樣式只有普通的開價寶貝一種，但隨著業務的發展，演變出拍賣、免費送、租房、玩家等細分領域的商品詳情頁（我們將細分領域的業務命名為“垂直業務”）。

圖2 閒魚詳情頁業務演變

此時，還不斷的在老的業務邏輯裡新增新的業務邏輯，導致所有的詳情業務邏輯堆在一起。於是乎，會出現下面的場景：

1）今天A詳情業務線的同學，加了段邏輯，掛了，影響了所有業務線的同學；

2）B詳情業務線的同學想做單獨的監控、快取、降級等，做不到啊，大家的邏輯在一起，改造成本太高；

3）C詳情業務線的同學本想只關注C詳情業務邏輯，發現所有業務都在一起，不得不將所有業務都理清楚一遍；

4）D詳情業務線的同學發現前面的業務邏輯太複雜，為了將影響面減少到最小，找了一個認為最安全的地方，加了一段D詳情業務的特殊處理。

圖3 詳情頁堆邏輯程式碼

有人可能會問，堆邏輯正常的啊，加幾行程式碼，業務就上線了，網際網路提倡的敏捷開發，當然是怎麼快怎麼來。但 敏捷開發 != 提需求 + 編碼 + 釋出 ，加幾行程式碼交付業務上線，可能會帶來眼前的收益，但一直這麼下去，程式碼會越來越臃腫，沒有設計和文件沉澱的系統，難以維護，出故障只是時間問題。

1） 業務沒有做隔離，所有的垂直業務邏輯都堆在一起，互相影響。

2） 詳情頁業務足夠的複雜，卻沒有統一的模型，形成統一的認知。

因此，架構的設計方案就著重解決這兩個問題。

1 業務隔離架構推導與設計

一個業務，有多種形態的實現，很容易對應到設計模式 裡的策略模式。 最粗暴的方式，每個垂直業務都自己實現詳情頁。

圖4 使用策略模式，隔離每個業務的實現

這種方式，業務雖然隔離了，但維護成本極高，新增一個通用的功能，所有業務都需要新增一遍。 因此需要 將共性內容（不變的部分）抽象出來，將變化的部分由各個垂直業務去實現。

圖5 抽象出共性(不變）和特性（變）的內容

這種方式，解決了業務的隔離，共性的內容統一維護，變化的部分由各個垂直業務獨立維護。但此時，所有的業務團隊還是在一個應用工程裡寫業務程式碼，會出現如下場景：

1） 開發階段，各業務線都在這個應用里拉取一個分支進行開發，整合部署時，程式碼衝突難以避免。

2） A業務線添加了一段自己業務線的邏輯，部署失敗了，導致其它業務線也無法使用。

3）

N業務線不在自己的團隊內，屬於外部合作團隊，如何新增該業務線的邏輯。

這些場景存在的原因在於， 業務程式碼雖然隔離了， 但人員的開發過程並沒有隔離。 有如下3中方法可供選擇:

a. 將共性的內容打成二方依賴包，每個垂直業務依賴這個二方包，進行獨立應用開發。

這種二方依賴的方法最常用，但在二方服務裡新增一個通用功能的時候，要告知所有業務方都升級二方包，還要發版，升級的成本高。

圖6.a 共性內容打成二方包

b. 垂直業務獨立應用開發，然後將程式碼打成jar包，再整合到共性業務應用裡，一起部署

該方法依賴關係跟方法a相反，但部署方式不夠靈活。如果要實現垂直業務的獨立部署，改造成本太高，需要做類隔離，budle隔離等。

圖6.b 垂直業務打成二方包

c. 綜合a和b的優點，將共性的業務獨立部署，垂直業務既可以獨立部署，也可以寫在共性內容應用裡。當呼叫某個垂直業務實現時，可以自動路由到具體的垂直業務實現（這個垂直業務實現可以是一個本地呼叫，也可以是一個遠端呼叫）。這樣，垂直業務的開發人員就可以在自己的應用中開發、部署、運維，解決開發人員的隔離問題。

圖6.c  互不依賴，部署方式可選

至此，業務的隔離，開發人員的隔離問題都已解決。但該架構方案顯然不只有詳情這一個場景可用，其他類似的業務場景也有相似的問題。因此，架構的程式碼不能與業務的程式碼耦合在一起，需要將架構的程式碼獨立出來，形成通用的技術工具，以應用於所有類似的業務，業務開發應該只關心業務的事情。我們特地為此開發了一個多實現“業務隔離”路由工具，最終的隔離架構設計圖如下：

圖7 總體架構圖

2 領域模型在詳情頁的使用

隔離的問題解決了，再來談談詳情頁的領域建模。

為何需要領域建模？好多java開發的同學，大都會遇到這樣的問題：1）一門OO(面向物件)的語言，寫出來的程式碼都沒有OO的感覺，到像是過程式的程式碼，面向物件的思想基本沒有使用到。2）雖然程式碼滿足了業務需求，但從程式碼中，完全看不到業務領域的影子，業務領域和程式碼是脫節的。3）隨著業務的越來越複雜，裡面的依賴關係梳理起來非常困難，業務模組沒有邊界可言。

為了不給後人挖坑，為了解決詳情頁複雜的邏輯，為了讓程式碼更有範，為了讓接手詳情的同學都有統一的業務領域認知，因此決定對詳情領域進行領域建模。

圖8 領域驅動設計-模型關係總圖

Eric Evans那本《領域驅動設計——軟體核心複雜性應對之道》經典書籍大行其道十幾年，網上關於領域建模的文章也是浩如煙海，自頂向下、自底向上、四色原型建模、問題空間領域模型抽象方法論也非常的多。但這些文章和書籍，要麼談論理論概念，要麼談論建模方式，對初學者來說，看完之後，還是寫不出相應的程式碼。

所以本文不在重複的去講領域建模的概念，直接通過閒魚詳情頁這個業務場景，講述建模的步驟、DDD的程式碼展示，給讀者一個更直觀的參考。

3 詳情頁領域建模

閒魚詳情頁是一個純展示的頁面，用一句話可以概括為，“詳情頁是包括：商品、賣家、買家、魚塘、認證、互動等內容的資訊聚合展示頁” 。

這裡我們使用四色原型建模法進行建模。上面的這句話最骨幹的內容為：詳情頁是一個“資訊聚合展示頁”（瞬間事件）。

圖9 詳情頁是一個資訊聚合展示頁

骨幹內容定義好後，為了更好的描述詳情頁是什麼，需要補充一些實體物件，詳情頁主要包含商品、賣家、買家、魚塘這些實體（人-物-地點）。

圖10 詳情頁中包含的主要實體

在此基礎上，進一步的進行抽象，使用者實體中，有賣家、買家這個角色存在；魚塘實體中，又有塘主、塘民角色存在（塘主也是塘民，所以塘主應該繼承自塘民）。加入角色後的模型如圖11所示：

圖11 詳情頁中的角色

最後，再把一些描述資訊放進去，

圖12 模型中補充描述資訊

圖13 詳情頁類圖結構

4 DDD程式碼展示

有了領域到模型，需要將模型再對映為程式碼。在實現詳情頁時，依據的是DDD中的定義。DDD中最主要的內容包括：entity、value object、aggregate、repository、factory和service （如圖8所示）， 以及Infrastructure, Domain, application和User Interface 分層結構，如圖14所示：

圖14 領域驅動設計分層架構

Infrastructure主要用於持久化資料的讀取和寫入；Domain為領域層，提供領域資訊，這是業務的核心所在；Application是很薄的一層，沒有業務邏輯，用來協調應用活動；User Interface負責使用者資訊展示。將這個分層結構對映到工程結構如圖15所示。

圖15 DDD領域建模工程結構

這裡的Applicaiton層沒有業務邏輯，只作為二方服務對外提供。此外，工程結構中沒有寫User Interface層，因為該應用是以二方服務提供，當然，如果提供REST服務，則可以寫在這一層。

多數的使用者對MVC架構比較瞭解，因此，圖16對比了DDD的分層架構和MVC的架構，以做參考。

圖16 DDD分層對比MVC分層

根據上文的模型抽象，領域物件主要有 ItemEntity, SellerEnity, BuyerEntity, FishPoolEntity，並通過詳情頁聚合根DetailAggregate聚合。

圖17 詳情頁聚合根

在圖15應用結構分層中，有3種類型的資料物件，DO物件表示持久化的資料物件， Entity為領域物件，DTO為對外的傳輸物件。

首先通過領域層的Repository，呼叫基礎設定層的Dao讀取DO結構，再使用Convertor轉為Entity領域物件。

圖18 Repository的定義

圖19 Converor轉化器的定義

領域entity處理各自的領域業務邏輯，然後通過領域層的DetailService，對聚合根DetailAggregate進行整體詳情頁業務領域處理。最後轉為DTO傳輸物件提供對外服務。

沒有任何一種架構可以適用於所有的場景，也沒有任何一個架構是最優的， 所謂架構，都在解決“邊界”的問題。 因此都需要從實際的業務場景出發，明確出問題的邊界在哪裡，要達到什麼樣的目標，再遵循一些基本的原則和方法，基本都能夠設計出符合自己業務特性的架構。接下來將會給大家分享一篇從不同的視角出發，進行的業務架構設計，敬請持續關注公眾號。