前言：

談到“架構”這兩個字，會有好多的名詞閃現，比如:分層架構、事件驅動架構、DDD、CQRS等。亦或者一堆的軟件設計原則，如：KISS原則（Keep it Simple and Stupid）、SOLID原則(單一責任原則、開放封閉原則、里氏替換原則、接口分離原則、依賴導致原則)等。甚至如狀態圖、用例圖、時序圖、活動圖等UML建模，GOF設計模式等。
本文不會討論這些架構概念，而是從閑魚詳情頁這個業務場景出發，分析出當前的業務問題和痛點，然后通過一步步的架構推導設計，解決這些痛點。隨著業務的發展，相信這些問題大家都會遇到。而解決問題的過程，或多或少的會用到上面的設計原則。

一：老的業務架構 - MVC架構

很多同學開始寫業務的時候，基本都會先建表，然后生成CURD，最后再堆業務邏輯，從DAO->Manager->Service->Controller一路寫到底。在業務小的時候，這種架構非常的簡單實用，可以快速的開發上線。
但隨著業務發展，人員不斷增加，老的架構難以支撐業務的發展，穩定性和效率受到極大挑戰。蠻荒時代已過，精耕細作的時代到來，急需一種更合適的架構來支撐業務的發展。
以閑魚的詳情頁舉例，在業務初期，詳情的樣式只有普通的開價寶貝一種，但隨著業務的發展，演變出拍賣、免費送、租房、玩家等細分領域的商品詳情頁（我們將細分領域的業務命名為“垂直業務”）。

圖2：閑魚詳情頁業務演變
?此時，還不斷的在老的業務邏輯里添加新的業務邏輯，導致所有的詳情業務邏輯堆在一起。于是乎，會出現下面的場景：
1）今天A詳情業務線的同學，加了段邏輯，掛了，影響了所有業務線的同學；
2）B詳情業務線的同學想做單獨的監控、緩存、降級等，做不到啊，大家的邏輯在一起，改造成本太高；
3）C詳情業務線的同學本想只關注C詳情業務邏輯，發現所有業務都在一起，不得不將所有業務都理清楚一遍；
4）D詳情業務線的同學發現前面的業務邏輯太復雜，為了將影響面減少到最小，找了一個認為最安全的地方，加了一段D詳情業務的特殊處理。

圖3:詳情頁堆邏輯代碼
有人可能會問，堆邏輯正常的啊，加幾行代碼，業務就上線了，互聯網提倡的敏捷開發，當然是怎么快怎么來。但敏捷開發 != 提需求 + 編碼 + 發布，加幾行代碼交付業務上線，可能會帶來眼前的收益，但一直這么下去，代碼會越來越臃腫，沒有設計和文檔沉淀的系統，難以維護，出故障只是時間問題。

二：新的業務架構 - 業務隔離 + 領域建模

吉德林法則講：把難題清清楚楚地寫出來，便已經解決了一半。 老的架構的問題，歸納起來講：
1.業務沒有做隔離，所有的垂直業務邏輯都堆在一起，互相影響。
2.詳情頁業務足夠的復雜，卻沒有統一的模型，形成統一的認知。
因此，架構的設計方案就著重解決這兩個問題。

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

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

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

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

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

這種方式，解決了業務的隔離，共性的內容統一維護，變化的部分由各個垂直業務獨立維護。但此時，所有的業務團隊還是在一個應用工程里寫業務代碼，會出現如下場景：
1)開發階段，各業務線都在這個應用里拉取一個分支進行開發，集成部署時，代碼沖突難以避免。
2)A業務線添加了一段自己業務線的邏輯，部署失敗了，導致其它業務線也無法使用。
3)N業務線不在自己的團隊內，屬于外部合作團隊，如何添加該業務線的邏輯。

這些場景存在的原因在于，業務代碼雖然隔離了， 但人員的開發過程并沒有隔離。有如下3中方法可供選擇:
a. 將共性的內容打成二方依賴包，每個垂直業務依賴這個二方包，進行獨立應用開發。
這種二方依賴的方法最常用，但在二方服務里添加一個通用功能的時候，要告知所有業務方都升級二方包，還要發版，升級的成本高。

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


b. 垂直業務獨立應用開發，然后將代碼打成jar包，再集成到共性業務應用里，一起部署。
該方法依賴關系跟方法a相反，但部署方式不夠靈活。如果要實現垂直業務的獨立部署，改造成本太高，需要做類隔離，budle隔離等。

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

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

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

圖7: 總體架構圖。

2.2.領域模型在詳情頁的使用

隔離的問題解決了，再來談談詳情頁的領域建模。
為何需要領域建模？好多java開發的同學，大都會遇到這樣的問題：1）一門OO(面向對象)的語言，寫出來的代碼都沒有OO的感覺，到像是過程式的代碼，面向對象的思想基本沒有使用到。2）雖然代碼滿足了業務需求，但從代碼中，完全看不到業務領域的影子，業務領域和代碼是脫節的。3）隨著業務的越來越復雜，里面的依賴關系梳理起來非常困難，業務模塊沒有邊界可言。
為了不給后人挖坑，為了解決詳情頁復雜的邏輯，為了讓代碼更有范，為了讓接手詳情的同學都有統一的業務領域認知，因此決定對詳情領域進行領域建模。



圖8: 領域驅動設計-模型關系總圖
Eric Evans的那本《領域驅動設計——軟件核心復雜性應對之道》經典書籍大行其道十幾年，網上關于領域建模的文章也是浩如煙海，自頂向下、自底向上、四色原型建模、問題空間領域模型抽象方法論也非常的多。但這些文章和書籍，要么談論理論概念，要么談論建模方式，對初學者來說，看完之后，還是寫不出相應的代碼。
所以本文不在重復的去講領域建模的概念，直接通過閑魚詳情頁這個業務場景，講述建模的步驟、DDD的代碼展示，給讀者一個更直觀的參考。

2.2.1 詳情頁領域建模

閑魚詳情頁是一個純展示的頁面，用一句話可以概括為，“詳情頁是包括：商品、賣家、買家、魚塘、認證、互動等內容的信息聚合展示頁”?。
這里我們使用四色原型建模法進行建模。上面的這句話最骨干的內容為：詳情頁是一個“信息聚合展示頁”（瞬間事件）。

圖9: 詳情頁是一個信息聚合展示頁
骨干內容定義好后，為了更好的描述詳情頁是什么，需要補充一些實體對象，詳情頁主要包含商品、賣家、買家、魚塘這些實體（人-物-地點）。

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

圖11: 詳情頁中的角色
最后，再把一些描述信息放進去

圖12: 模型中補充描述信息


有了模型的設計，再轉為類圖設計。根據模型的抽象，詳情頁是信息展示的聚合，因此它是個聚合根，包含了商品、賣家、買家、魚塘這些實體信息。 商品信息描述里，又有視頻、圖片、文本、互動等信息。視頻、圖片可以抽象為媒體信息。使用UML設計出最終的類圖，如圖13所示

圖13: 詳情頁類圖結構

2.2.2 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傳輸對象提供對外服務。

三: 總結和思考

本文從詳情頁業務出發，當業務越來越復雜時，如何做業務的隔離，做開發人員的隔離，以及如何通過領域建模，形成統一認知。給大家提供一個可行的參考。
但沒有任何一種架構可以適用于所有的場景，也沒有任何一個架構是最優的，所謂架構，都在解決“邊界”的問題。因此都需要從實際的業務場景出發，明確出問題的邊界在哪里，要達到什么樣的目標，再遵循一些基本的原則和方法，基本都能夠設計出符合自己業務特性的架構。

接下來將會給大家分享一篇從不同的視角出發，進行的業務架構設計。

?

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的架构的“一小步”，业务的一大步的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。