> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/zh-hant/2020/w27-domain-driven-design-and-frontend-backend-interaction-patterns.md).
# W27-領域驅動 & 前後端交互模式
#### **關於領域驅動設計的一些思考**
**如何在快速變化中，保持我們項目核心的穩定。不至於在後續迭代中，複雜度失控直至重構。**我們現在其實已經面臨業務知識在團隊傳播中丟失的問題了，隨著團隊規模的擴大，人員的更替，問題只會越來越嚴重。那**核心是什麼，就是對業務的理解與抽象，映射到軟件設計中，我認為就是基於領域的設計。**
相比前端，後端往往在設計上做的更加詳盡、更加深遠。項目需要建立在對業務的深入理解之上，理解的越深刻，抽象的越徹底，項目的可維護性和擴展性越好。某種程度上講，後端不做設計，可能根本沒法開工。
前端就不太一樣了，我們的技術方案，更多的體現在單純的技術要點上，以及業務流程的實現上。真正在業務的深入拆解上，還做得不夠。說實話，**我們的方案設計，基本上還是停留在面向頁面的實現**。很少看到對業務進行抽象，進而設計組件和軟件的結構層次。
好的後端項目，它的表結構和service層是相對穩定的，這得益於對於業務領域的深刻理解與抽象。商家端現在正處於業務快速迭代的階段，相應地，在UI、交互上也會快速變化。如何最大程度地做到“以不變應萬變”？如何在整體上，以更低的成本去支撐業務成長？我想在領域驅動設計中找到答案。
拿收銀臺舉例，這次i版重構，是以容器組件和展示組件這個思路去組織整個應用的。容器組件負責狀態管理和業務邏輯，展示組件是只負責數據與視圖映射的純組件。收銀臺前端的業務邏輯並不算複雜，但這樣下來，容器組件也有600餘行。現在來看還比較清爽，但馬上就會加入貸款支付、理財金支付、營銷等業務，容器組件會越來越厚。怎麼辦？必須拆。怎麼拆？按領域拆。收銀臺前端的核心是對支付方式的處理，應該對不同業務屬性的支付方式進行領域抽象。每種支付方式對應的資產提供方不同，所以可以理解為一個領域。不同的領域有其特有的屬性與行為。比如，快捷支付，有卡列表的屬性，有選擇某張卡去輸入密碼的行為。貸款支付，有分期期數、金額的屬性，有去人臉識別貸款的行為，有獲取貸款合同的行為。這些是業務邏輯的底層，是相對穩定的。不管未來UI怎麼變，項目的核心———領域層不會變。甚至前端技術棧從Vue轉換到React，也可以做到核心的穩定遷移。
在設計這方面我之前也做的比較弱，對於領域驅動設計的構想還需要繼續交流與碰撞，進而得到進化。
#### **前後端數據交互模式的一些體會**
與錢包的業務相比，支付這邊的業務在前後端接口交互上，有著明顯的設計差異。支付業務中，像收銀臺、綁卡、買單等業務。對前端提供的API，基本上是面向頁面設計的。接口之間的關係，完全按照人機交互時的時序進行設計，前序接口會返回後序接口的url，請求參數，以及當前頁面所需要的一切，就差直出渲染後頁面了。
這樣做的好處是，前端的職責基本上集中在人機交互上，看起來職責很單一。後端在接口交互上，可以有相對靈活的控制，可以自由決定後續接口，進而調用不同的下游，最終返回數據，避免了與前端協商的過程。
不好的地方也很明顯，這種模式把API和視圖，或者說人機交互流程，緊緊地耦合在了一起，在擴展性上其實是很脆弱的。這種協作模式之所以成立，是因為前端視圖和業務流程足夠穩定。事實上，支付業務確實比較符合這個前置條件。這種模式雖說普適性差了些，但既然支付業務在架構的時候就這麼做，一定有一些比較深入的考量。目前來看，在支付的場景下，我說不上絕對的好與壞，還需要在做業務中體會。
**快捷支付項目中，A接口下發接下來的請求接口，決定後續接口。需要後端對前端版本有感知，要不通過版本號，要不通過以客戶id為線索的全鏈路灰度。**