前言：
談到“架構”這兩個字，會有好多的名詞閃現，比如:分層架構、事件驅動架構、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傳輸對象提供對外服務。
三: 總結和思考
本文從詳情頁業務出發，當業務越來越複雜時，如何做業務的隔離，做開發人員的隔離，以及如何通過領域建模，形成統一認知。給大家提供一個可行的參考。
但沒有任何一種架構可以適用於所有的場景，也沒有任何一個架構是最優的，所謂架構，都在解決“邊界”的問題。因此都需要從實際的業務場景出發，明確出問題的邊界在哪裡，要達到什麼樣的目標，再遵循一些基本的原則和方法，基本都能夠設計出符合自己業務特性的架構。
接下來將會給大家分享一篇從不同的視角出發，進行的業務架構設計。
閱讀更多 阿里云云棲社區 的文章
