戲說領域驅動設計（六）——限界背景關系——設計

　　限界背景關系（簡稱BC）是一個很難講的部分，我尋思著是不是再多找一找文章，看看其它人怎么講的，但猶豫再三還是決定按自已的理解去聊，各種找材料就有點剽竊的行為了，至于說的是否正確，您務必也要做好判斷，畢竟每個人都會有自己的理解，做為溫故而知新的一部分，在此把前面總結的BC的特點再重復一下，也不是為了湊字兒，DDD這東西就得靠多多的啰嗦才能記得住，畢竟概念忒多，此外，為提升您的閱讀體驗，限界背景關系分為兩節分別講解，

　　BC的特點包括四個方面：1）是系統的物理劃分；2）應根據子域的定義進行推導；3）限定了領域模型的邊界，是對領域模型的一種劃分和限定；4）BC內每個領域術語都有且只有一個明確的含義（即通用語言），

　　BC的設計一般是通過子域進行推導，假如將DDD的指導分成三部分：子域設計、BC設計和代碼設計，BC屬第二層，起到承上啟下的作用，在將業務模型轉換為技術的程序中提供宏觀指導，BC定義的程序其實就是確認有幾個子系統（或Java中的包、.NET中的名稱空間），有哪些領域模型（此處的領域模型是一種業務術語不是指‘類’或‘介面’）以及子系統間如何互動，從上述概念上可以看出來，討論BC時既有業務的部分也有技術的內容，

　　在進入BC的討論之前，首先介紹一些基本概念避免后續我們用到的時候作為讀者的您一臉的蒙圈，怪我不事先說事后賣關子，第一個介紹的詞叫“建模”，第二個要介紹的詞是“模型”，不論是作為軟體開發老炮兒還是菜鳥，您可能在無數的場合聽了無數次的這個詞，遙想當前我初來乍到，但凡聽誰說在做軟體建模，給我的第一印象就是這人妥妥的大牛一個，那它到底是什么意思呢？咱換成人話就是：比如有這么一個事兒，我嘴笨和您說不明白，那就寫一段兒或者畫個圖，反正不管用什么手段，只要您懂了我的意圖咱這目的就達到了，這里所說的“一段文字”或“圖”就是模型，干這個事情的程序就叫“建模”，所以您不管是做設計子域還是BC還是畫流程圖，都是建模，不知道為什么非得用“建模”，IT圈就是不喜歡說人話，

　　題外話：中國IT圈對一些詞的翻譯我覺得真是前無古人：句柄、多型、建模、閉包……這翻譯，不服來戰，

　　回到正題，在軟體設計活動中（嚴謹的說是在UML建模程序中）包含三類模型：業務模型、分析模型和設計模型，具體解釋如下串列，不過咱得多說一句，我們常見的類圖啊、時序圖啊，你可別認為這些模型僅用于實施前的設計階段，在業務分析階段也是可以用的，只是目的不一樣，您可別回頭一說類圖就認為只在軟體設計階段專用，對外行說說就行了，內行咱得有內行的專業素養，

• 業務模型：用于解釋與說明業務邏輯的各類檔案或圖，與是否有電腦無關系，是對客觀的業務的描述，子域設計即是業務模型設計，
• 分析模型：用于說明哪些業務可在軟體系統中實作（并非所有的業務都可被落實到軟體中，這就是為什么常常見到開發與產品經理互撕），其上面連接了業務模型下面對應到設計模型，BC設計即分析模型設計，
• 設計模型：用于說明軟體在代碼層次上的設計方式，常見的如類圖、活動圖、時序圖等，DDD戰術階段所建模型如聚合、物體即為設計模型，

　　 我不僅說了三個模型還能套在DDD上，一是沒跑題，二是顯得專業，能這個事兒圓回來，我自己都佩服自己，另外著重說一點，所有的模型里，檔案是最重要的，具體您自行體會，關于檔案這個事情，也再多啰嗦幾句，一般來說不建議花精力在代碼設計階段撰寫大量的檔案，一是會很占用時間二是幾乎沒有多少公司能保證代碼變化的同時檔案也隨之變化，在此情況下檔案不僅不能說明問題還特別耽誤事兒，But，業務模型檔案是必需的，這東西變化率不是很高，您也別跟我抬扛，一個企業的業務模型天天變化，我勸您趁早離職，他自己都沒找到方向，至于分析模型，屬于過渡型檔案，視具體情況而定，

　　上一章中展示了個人微信的域圖，為避免誤會本節以一款“即使通訊軟體”的后端架構為例展示限界背景關系的設計圖，由于并無實際的軟體，您仍可以微信為對照，我得先避個嫌疑，回頭騰訊公司找過了就蝦米了……另外，實際的系統架構比案例復雜的多的多，劃分得也會更加的詳細，此處僅做為引子告訴您如何進行BC設計，您在日常作業中需要學會舉一反三，這也是治學問的正確姿勢，時間久了，你就能體會何為“眾里尋他千百度，驀然回首，那人卻在，燈火闌珊處”，

 　　為能說明問題，本例中把“小程式管理子域”和“鑒權子域”去掉了，圖不好畫（其實主要是影響您的閱讀體驗），此外，上一章針對“通訊錄子域”和“聊天子域”的設計不夠細致，需要進行細化，下圖為兩個子域的細化結果，注意：此處的設計仍為子域圖，尚未到BC設計階段，

 　　子域經過細化后我們建立了下面的BC圖，需要注意的是BC設計圖中應該以實線表示每一個限界背景關系，因為BC具備物理特性已非概念上的模型， BC間的互動通過實線進行連接，

  　　BC的設計不僅需要子域設計為參考，還需要結合您的團隊與公司的實際情況進行計，本案例的建設由同一部門的人數為200的成員所組成的團隊，包括研發、測驗、運維、產品經理、專案經理等基本角色，因資源充沛且崗位齊全，確定使用微服務架構作作為系統落地時的方案，我們來詳細解釋一下本方案的設計依據，

1. 聊天子域：分為“通訊管理”和“歷史訊息管理”兩個子系統，前者用于聊天場景比如發送各類文本、圖片等；后者用于對歷史訊息進行存盤以用于記錄查詢，這兩個BC所關注的業務點有很大差異，邊界較為明顯，兩個BC可使用不同的系統架構并可獨立進化，
2. 訊息審計使用了第三方采購的實時審計系統用于對用戶所發的朋友圈或訊息進行審計以避免非法內容的存在，
3. 通訊錄子域分為兩個BC：“聯系人管理”和“好友關系管理”分別用于管理本賬戶的聯系人和用于朋友推薦的推薦系統，

 　　一般來說BC和子域是可以一一對應的，當然，具體情況還要視您所在公司和團隊的架構，假如說子域的設計是專案的開端，那BC的設計的好壞幾乎可以決定系統的成敗，應當是設計程序中投入精力最多的地方，其原因前面已然說過：子域劃定了一個個小的物理系統，天然具備隔離效果，當您的系統具備良好的BC設計時，即便某個BC出現失敗也不會導致整個系統的業務雪崩，后面我們談到DDD的隔離機制時您就會發現為什么BC的隔離是最為核心和關鍵的，

　　BC的設計粒度，往大了看其實可以是一個子系統本身，單體系統只有一個BC（此種情況下，單系統已經不能算是純粹上的BC，應當以“包”或“名稱空間”作為BC的基本單位）；往小的方面看，最小的粒度為“聚合”，切記！真的不能再小了，無論其大小，關鍵的設計原則是“完整”即BC可以完整的支撐某項業務，換另外的說法就是每個BC應該是自治的且與其它BC有清晰的邊界，實際上，當您在BC設計時會發現大部分情況下尋找BC邊界是一個非常自然的程序，還是那句話：人是有靈性的，

  　　實際上，BC的設計程序中還是有許多的原則可以遵守的，在此一一列舉出來，

1. BC的設計是系統的宏觀架構設計，一經確認后就需要以此為依據進行實施
2. 以業務維度為準進行BC設計，這一潭訓存在例外：前后端分離架構，是一種比較典型的以技術為參照的的BC設計方式，就前端是否屬于BC一部分的問題目前還是有一定的爭議的，比較權威的書上的回答也是“Yes”，為此還引入了微前端的技術，我個人建議您視自己的公司與團隊情況而定，不必拘泥于理論，
3. BC設計需要以您的組織結構包括團隊技術層次、團隊組織結構、是否跨部門、人力資源情況等為參考以免雖有設計方案但無法落地，陷入紙上談兵的境界，造成前期作業浪費，
4. BC也需要保持隨時變更，尤其是在子域有變更的情況下
5. DDD中最為重要的規律是“運動與適應”，一切事務皆在變化中，您需要隨時根據變化做調整
6. 現實中，有些帶頭大哥喜歡根據開發任務來設計BC，這種情況最好少用以減少甩鍋的情況，另外，個人建議BC的開發作業只由一個人負責即由上面的service到最下面的dao，不要針對同一個聚合讓過多的人參與，每個人都有自己的設計思路，非常容易出現重復性的內容；一個研發人員的連貫性思路也很容易被打斷，如果BC較大，也請限制在一個團隊內以減少溝通成本
7. 限界背景關系的識別實際上并沒有標準可言，可以通過業務復雜度、管理復雜度和技術復雜度去分析和識別，迭代化的進行分析 ，

　　為了讓您明白，我們再整一個例子，這里以一個電商購物系統為例，展示其BC的設計方式，本案例中，團隊人員較少，由開發人員承擔著運維的職責；系統客戶物件以企業內部用戶為主，為方便說明，我們仍只展示部分子域：核心域中的銷售子域，如下圖所示，

　　依據上圖所示的子域說明，推匯出如下BC設計，

　　不同于第一個案例，本例未使用微服務架構，而是使用了單體架構作為其落地方式，我知道有些人是強烈的微服務架構擁護者，但我仍然需要在此強調：系統的架構選擇時，技術能力僅僅是一方面，而且還只是很小的一個方面，決策我們架構選擇的因素有許多，比如團隊的綜合能力（注意：不能以團隊中是否有一兩個高手來決策團隊綜合能力）、團隊結構、公司的總體結構（尤其您要做的系統是業務中臺時）等，專案背景中已說明“開發兼職運維”，說明當前團隊使用容器化部署、鏈路追蹤、全堆疊監控等技術時會比較勉強，即使強加到系統中也會由于資源的不足造成您想要的結果與期望不匹配，

　　最后需要說一句，我們都知道微服務架構有各種優勢，也知道單體系統有各種不足，但任何事務都有其兩面性，在您使用的時候需要首先綜合評估自身所具備的條件，再說了，您做的系統不是一錘子買賣，隨著后續資源的投入，您是可以進行架構優化的，

標籤：其他

上一篇：java 往 pdf 插入資料 (pdfbox+poi)

下一篇：(翻譯) CAP 理論 FAQ