領域驅動設計問題域分析-以bilibili OGV業務為例

領域驅動設計作為一種設計思維方式從被提出到現在，社群也不斷豐富了領域事件，事件溯源，CQRS等設計元模型。隨著個人對領域驅動設計的理解不斷深入，結合自身在專案中的實踐經驗，以目前bilibili OGV的業務為例透過領域驅動設計的分析設計建模方法，試圖說明領域驅動設計的統一過程和思考方式，本篇文章只包含問題域分析，沒有提及架構，設計模型和編碼層面的內容。文章透過對價值需求分析方法，獲取問題領域相關利益者，在相關利益者的基礎上透過分析業務需求的業務流程和業務場景，在業務需求分析結果的業務流程圖和業務用例圖基礎上，透過領域識別和劃分得出領域劃分結果領域對映圖讓問題領域變的清晰。

在Eric Evans 的領域驅動設計中提到，領域驅動設計作為一種思維方式，根本目的是為了加速那些需要處理複雜領域的軟體專案開發，應對軟體核心複雜度的挑戰。那麼軟體的複雜表現在哪裡，在《A Philosophy of Software Design》中提打到：Complexity is anything that makes software hard to understand or to modify,任何使軟體變的難於理解和修改的因素都是複雜性。

隨著需求的變化，系統規模會不斷擴張，軟體複雜度會增長，除了需求功能本身的增加，還有功能之間的聯絡變的牽一髮而動全身，並且這個複雜度的增長往往是指數級的趨勢，在構建軟體過程中，無法避免的技術債造就軟體無法躲避的熵的增加。這樣造成了軟體相關人員需要掌握大量資訊，提升自己對業務需求和軟體的理解。

為了滿足非功能性質量需求，例如高效能，高併發，我們考慮在系統中引入快取，併發處理，CDN，非同步訊息，海量資料的分散式儲存，海量資料的高效分散式計算等這些都讓系統在結構上變的複雜。
為了保持系統有序，提高程式碼可維護性，我們利用分層架構達到不同層次職責分離，但這種分解，也帶來了溝通成本的增加，管理上的挑戰，這一點在康威定律（Conway’s law）早已說明，任何組織在設計系統時，所設計的方案在架構上都和該組織的溝通結構保持一致。

為了降低業務複雜度，我們拆分不同的子領域，但是往往因為守不住領域的邊界而喪失了拆分的價值，系統結構會變的越來越混亂。結構上的混亂，會讓軟體的修改變的不確定。

在設計軟體系統時，設計人員是無法完全預測系統的變化，一方面可能過於考慮變化的影響，而進行了過度設計，但是預期的變化未發生，那麼過度的設計所付出的成本就是浪費，另一方面，如果不對變化做任何的預測，系統會非常的僵硬，不停的因為變化而不斷的付出較大成本。

參考圖1-1，這些軟體系統本身客觀的結構,規模，變化複雜性都阻礙了開發人員對系統的理解，為了應對這些複雜姓對開發人員在理解能力，認知增加和預測業務變化方面有較高要求。

^圖1-1

領域驅動設計引入了一套提煉為模式的設計元模型，對業務軟體系統做到了規模的控制、結構的清晰化、和變動的響應。

• 領域驅動設計面對業務需求，由領域專家和開發團隊進行需求分析和知識提煉，從問題的需求中提煉統一語言，透過分而治之拆分領域，分解問題空間，確定核心子領域，通用子領域和支撐子領域，根據業務能力劃分出不同的獨立自治的限界上下文，再透過上下文對映管理它們之間的關係，參考圖1-2。
  每個限界上下文都是一個獨立的自治單元，根據限界上下文的邊界，劃分團隊，團隊為所屬的限界上下文負責，團隊除了需要了解限界上下文的協作介面，確定上下文對映的模式，就只需要瞭解邊界內的領域知識，建立各自的領域模型，透過限界上下文的分解控制系統複雜度。

^圖1-2

• 軟體系統的構建本質是從真實世界的問題中尋找解決方案，真實世界的客戶需求可以簡單分為業務需求和質量需求。質量需求一般包括安全，高效能，高併發，高可用性等，往往在技術實現上帶來挑戰，為了避免業務需求帶來的業務複雜度與技術實現複雜度混合，需要確定業務邏輯和技術實現的邊界，隔離兩者，這種隔離也符合關注點分離的設計原則。領域驅動設計引入的分層架構規定了嚴格的分層定義 ，將業務邏輯封裝到領域層，支撐業務邏輯的技術實現放到了基礎設施層，領域層之上的應用層一方面暴露應用服務介面，另一方面又充當業務邏輯和技術實現的協調器，參考圖1-3。實際分層架構在實踐中已經有多種演化：Clean Architecture中的整潔架構，Alistair Cockburn提出的六邊形架構，Jeffrey Palermo 分層思想的 洋蔥架構。

^圖1-3

• 領域驅動設計透過領域模型針對限界上下文進行領域建模，形成結合分析，設計，實現於一體的領域模型，對業務需求抽象過程中，提取領域知識，保留面對變化時的擴充套件性。Eric Evans給出了戰術的設計元模型，透過領域服務，領域事件，實體，值物件等來表示模型，並透過實體和值物件訪問資源，維護完整的聚合，進一步對聚合和值物件進行封裝設計，在實際設計和實現中做到對變化的響應。

領域驅動設計體系構建在設計元模型的基礎上，並沒有特別的規範指導設計的過程，那麼如果沒有掌握其精髓，和較高的技能比較難合理運用這些設計元模型，領域驅動設計缺乏一個系統的統一過程作為指導，團隊在運用領域驅動設計時，較多取決於設計人員的行業知識和設計經驗。

針對Eric Evans的領域驅動設計，社群中也提出了一些不足和解決方案或模式。

1. 領域驅動設計缺乏規範的統一過程指使其設計過程更具可操作性。

2. 領域驅動設計缺乏與之匹配的需求分析方法探索明確的問題和領域知識。

3. 領域驅動缺乏規範化，具有指導意義的架構體系，使從需求到限界上下文和上下文對映的識別，到業務架構，應用架構，技術架構的分析對應提供參考。

4. 領域驅動設計缺乏固化的方法指導領域分析建模、設計建模，實現建模過程，主要憑藉建模人員的經驗。

在張逸的《解構領域驅動設計》中提出領域驅動設計統一過程（Domain-driven design unified process,DDDUP），相信很多人對統一軟體過程（Rational unified process,RUP）並不陌生，不同於RUP的軟體專案管理過程，書中提出結合領域驅動設計對問題空間和解空間的階段劃分、對戰略設計和戰術設計的層次劃分，將DDDUP分為三個連續階段：

全域性分析階段

架構對映階段

領域建模階段

每個階段都規定了里程碑和產出物，參考圖1-4

^圖1-4

下面以bilibili OGV業務為例，如何做領域驅動設計的問題領域分析，能夠透過一定的分析方法，輸出相應的可清晰識別的結果，讓我們逐步認清業務問題。

領域驅動全域性分析主要目的是明確問題，輸出價值需求和業務需求，從價值需求維度搞清楚問題的界定和約束，獲取利益相關者，系統願景和系統範圍；在業務需求維度梳理業務流程弄清楚其中每個角色（利益相關者）如何參與到一個完整的流程中，視覺化的輸出業務流程圖與業務用例等說明每一個提供業務價值的業務流程，透過業務用例呈現角色和目標系統的功能性互動，在這個階段只是對問題的探討，無需考慮如何實現的細節。

在《有效需求分析》中將應用類軟體需求透過目標/願景分析，干係人識別，干係人分析關鍵任務分析價值主線需求；透過功能需求，資料需求，非功能性需求分析的關鍵任務等識別業務詳情需求。
解構領域驅動設計的書中，作者提到全域性分析的5W模型，參考圖2-1，透過探索這5W關鍵要素，搞清楚問題領域。

在圖2-1中，首先需要透過分析問題相關的利益相關者（干係人），和這些角色透過訪談，頭腦風暴，討論等方式獲取系統的願景目的，針對願景目的，分析達成目的，解決問題的業務需求有哪些（提供什麼樣的產品或者系統來達成對應的願景），這裡在下文的業務需求分析中會透過業務流程和業務場景的分析和最佳化思路，得到具體的業務需求，即具體問題呈現。

^圖2-1

根據價值交換理論，影響價值需求的會有價值交換的兩方面，目標系統業務需求輸出價值的受益者和解決業務需求的支持者，支持者包含所需的資源或者支援的利益相關者，例如OGV內容的消費使用者就是典型受益者，而促使OGV內容生產出來，使使用者消費到這一系列內容的系統能夠成功的投資人，監管者，合作的文化公司，員工等都是支持者。參考圖2-2

^圖2-2

在價值需求分析時，支持者更為重要，因為他們決定了目標系統的願景和範圍，確定開發目標系統的約束條件；在業務需求分析階段，受益者更為重要，他們決定了系統的業務流程和業務場景，但是這些業務場景必須要獲得支持者的認可。

在實際價值需求分析中，一般會從兩個角度識別利益的相關者：

一個角度透過目標識別利益相關者，從組織架構角度瞭解組織相關人。從OGV關聯組織架構看，從版權合作採購，製作出品，運營，大會員，市場，BI，商業化，媒資內容生產運營，支援部門的財務等部門負責人，分支部門負責人都是價值需求的關鍵干係人。

另一個角度透過風險識別其他利益相關者，具有一票否決權的評價者的關鍵干係人，業務負責人，技術實施存在風險的開發團隊關鍵干係人，監管風險相關的法務部門等
這個方面來說，OGV業務所涉及的利益相關者是較多的。

在相對高的層面也會透過商業模式畫布看價值需求
作為面向內容創作者（UP主）和內容消費者的內容平臺，OGV內容作為其中重要的一部分，OGV內容消費者是平臺消費者的一部分，但是在供給端和UGC完全不同的模式。

我們常常會把領域專家，開發團隊等組織在一起基於商業模式畫布的指導和規範下，透過頭腦風暴的方式可以有效的啟發和約束思維明確明確價值需求，同時有助於在目標系統的價值需求上達成一致。

參考圖2-3

^圖2-3

在過往遇到的相當多的需求中，非常的缺少對於需求價值的描述，或者描述的方式言之無物，放之四海而皆準，例如定性描述“提升投放的效率”，“改善使用者體驗”，這樣的目標無法指導、衡量系統的開發和實施。確切的搞清楚和描述價值，另一個層面是為了更加明確問題的影響面，優先、重要程度。

首先建議定量描述，遵循SMART原則，使用具體，準確的資料描述，例如：透過系統自動產出投放圖片物料（Attainable），在功能上線後2個月內（Time-based），將OGV內容投放時的圖片物料製作效率（Specific），從每月12人天降低到3人天，提升對應渠道投放的及時性，同時做到60%內容可以在特定渠道A的自動投放（Measurable），從而提升投放效率（Relevant）。理論上大多數的需求都是可以找到定量描述的方式衡量價值。

其次，在無法定量衡量的情況下，最好可以場景化描述，
最後，不建議任何模糊的定性描述，在目前的一些網際網路使用者端需求價值驗證中，無法直接確定價值的情況下，也會大量使用A/B實驗等手段進行方案驗證，但是這種方式在複雜的業務問題中不一定合適，因為能夠開啟實驗的研發成本過高。

業務需求是實現價值的具體內容，用來清晰地表達利益相關者對於目標系統提出的業務功能要求，這裡的需求一定要在使用者視角展開，而千萬不能受所謂“功能”的影響，將解決方案當作需求。業務需求必須在價值需求的指引下，明確各個利益相關者的前提下，在支持者的幫助下，考慮受益者的目標，思考目標系統應該為受益者提供什麼樣的服務。

在實際分析業務需求分析過程中透過兩個方面看價值和目標：

1. 透過分析業務流程體現流程完整的業務價值

2. 透過一個階段內滿足多個利益相關者的業務目標，達到一個階段性目標，或者為某個利益相關者提供全方位的服務。

業務流程必須要完整的體現端到端的服務過程，要有因有果。通常情況下，業務流程的起點由一個角色發起服務請求，但是完成整個業務流程，需要多個角色共同參與協作，那麼梳理業務流程時必須全方位觀察目標系統以及其所在的組織，確定各個角色在流程中應該履行的職責和協作的順序。

業務流程的發起，有外部使用者發起的服務請求，組織內員工發起的請求流程，管理職能發起的服務請求。呈現業務流程最直接的方式就是業務流程圖，視覺化的方式簡單清晰表達業務本身運作方式，明確業務規則，以OGV業務為例，用泳道流程圖呈現使用者，內容提供者，內部運營，平臺之間的關係。參考圖2-4

^圖2-4

這個整體的業務流程涉及到組織內外的各個角色，部門之間的協作，並且不存在主次之分，都是參與流程的協作方。流程中的執行活動都是為了滿足最終的業務價值，但是執行環節的操作目的和意圖都不相同，組織內的一些執行流程對服務請求的發起角色而言，大多是不可見的。一些提供支撐或者管理意圖的活動可能會出現在不同的業務流程中，例如流程中的採購活動，也同時出現在公司其他業務中。影片製作和稽核對於UGC業務，直播業務也同樣需要。從這個角度來說，業務流程不僅需要有端到端的完整性，還需要有邊界，職能邊界和系統邊界。

那麼如何識別業務流程？在實際的識別過程中，通常我們會先外後內，先業務後管理。

1. 識別外部引起的主，支，變業務流程，外部服務請求引起的業務流程大多是外部客戶和使用者，因此先識別這些，參考下圖2-5。

2. 內部發起的主，支，變業務流程，例如運營評估流程，授權IP版權流程等參考圖2-6。

3. 識別管理流程，管理類的流程一般是管理者為了控制業務開展，規避風險，控制結果，一般會涉及事前預防的管理，事中的審批、規則，事後的分析的報表和資料分析，例如活動預算申請，OGV版權的立項評估，採購合同審批，上線後的劇集內容的播放量，時長，引入的大會員人數等資料分析。

^圖2-5

^圖2-6

識別了相關的業務流程之後，需要對這些業務流程進行相關的分析和最佳化，

首先業務流程是有層次的，以圖2-4的OGV業務流程圖為例，基本上這個流程圖的每個節點都是一個複雜的子流程，同時這裡的參與方有不同的細分，例如內容提供者包含外部媒體公司，也包含內部的動畫製作中心等，運營包含，版權運營，內容運營，媒資運營，大會員，商務，BI等，使用者也包括了，大會員使用者，普通使用者等使用者差異，我們這裡合併看待是為了有一個能夠表達整體業務端到端的流程，如果開始就把這些差異全部表達，這個流程會變的非常的複雜，而無法看到業務流程的全貌。

其次業務流程分析的關鍵是分析：分工，活動，協作，分支，管理層面的稽核，規則，異常。

這裡按照分層，業務流程最高的組織級流程（圖2-4），為了更好說明OGV業務的細節，表達部門間的協作，細化部門級的業務流程呈現圖2-4中的影片生產子流程圖2-7。

^圖2-7

這裡OGV影片介質的生產除了OGV事業部的內容運營，媒資，OGV平臺，主要需要其他合作部門版權運營，主要的稿件平臺，影片雲平臺的協作完成OGV影片的生產。

根據圖2-5，圖2-6 提供的分析思路，正常OGV影片生產業務流程是圖2-7這樣的，那麼提供的這樣的服務請求有變體流程嗎？當前業務確實已經存在，例如：OGV透過和UP主合作對UP主創作影片進行收錄，那麼這些影片引入OGV劇集的方式和圖2-7的流程是截然不同的，除此之外還有，機器發起的針對正片影片生產的高能看點的生產流程，同時機器發起生產的拆條影片的生產流程和圖2-7的業務流程都會存在差異，這些都是區別於主服務請求的一些變體服務，篇幅問題這裡就不詳細展示具體的變體流程。

當然，為了更好服務我們的使用者，仍然存在一些支撐的流程，如果圖2-7中生產的影片在釋出上架之後，影片中的某些特效，字幕，影片片段存在瑕疵，甚至是錯誤，那麼這個時候，內部OGV媒資需要發起影片換源流程進行影片的重新壓制換源，這裡就需要我們有清晰的支撐主業務流程的流程來支援影片換源。

業務流程分析產出業務流程圖，這個過程中透過不同層次的業務流程的分析識別出主要核心業務流程和變體業務流程，同時兼顧到異常的支撐業務流程。實際實踐中，通常只需要對業務流程進行分析，但有時不可避免要對部分的關鍵流程進行最佳化，流程資訊化之後，有必要對線下手工流程進行適度的最佳化。

這裡針對不同的使用者，不同目的發起的業務流程的分析結果，是下一步分析業務場景的重要依據。

對於業務場景，通俗直觀的可以認為是為了實現一個業務目的，角色和角色，角色和目標系統之間在特定時間進行的互動行為。

在理解業務需求時，對業務流程進行了分析，最佳化之後，那麼接著需要識別流程中存在哪些和系統相關的業務場景。業務場景是以使用者為中心，描述使用者的操作行為，體現使用者對產品的使用狀態。這裡分析業務場景的本質是為了瞭解使用者在什麼場景下需要系統的支援，為什麼要提供這樣的系統功能，為判斷決策提供依據：實際交付進度要求，系統效能的要求，易用性的要求，部署環境的要求等提供使用者場景依據。

通常情況下我們會如何識別業務場景呢，有兩種常用的方式：

一. 透過業務流程識別業務場景

透過識別業務流程中的角色和場景，就可以較容易清晰的知道特定角色和角色，角色和系統之間的互動行為，進而知道系統需要提供的服務。

在圖2-7中OGV平臺提供劇集單集建立和劇集單集上架功能，進而C端多渠道使用者才能觀看到相應的影片作品內容，同時這裡還隱含系統之間的擴充套件功能，在劇集分集上架時對稿件平臺稿件開放。如下圖3-1:

在圖2-7更細化的業務流程(這裡不再展示)中，我們分析到內容運營角色和其他角色互動，以及和系統互動來完成特定的目標，例如，為了在特定時間劇集分集，透過設定定時上架時間，完成內容上架，以達到C端使用者可以觀看內容，這裡透過用例圖來表達業務場景。

^圖3-1

這裡需要特別強調，

1. 詳細的某一用例的表達，不能只是體現系統功能，核心要體現實際角色在什麼場景下需要這個功能，例如圖3-1中，系統提供功能更新劇集分集的釋出時間，這個系統功能的一個使用原因：劇集分集延遲播出

2. 在分析場景過程中，會經常出現隱含在系統內部的處理邏輯，比如校驗，檢查，上面提到的釋出上架過程中對稿件平臺的稿件開放動作，沒有作為用例出現，這個是業務邏輯，從用例抽象角度來說，不應該讓角色直接感知，會造成干擾。

3. 在圖3-1中有擴充套件關係的用例，本質上，這些擴充套件用例可以抽象泛化來表達，但是這麼識別和擴充套件表達地目的也是為了讓實際角色更直觀感受到場景，抽象泛化會讓角色困惑。

在透過業務流程識別了角色和業務場景之後，需要對業務場景進行補充，常見如由時間、狀態而觸發的業務場景，如圖3-1中的定時上架，某個內容因為版權到期的狀態變化，導致內容需要進行下架的場景。

二. 對無業務流程業務識別業務場景

通常我們需要回歸到業務場景的基本構成來看，業務場景本質體現了，角色（Who）在特定空間（where）的特定時間（when）為了達成一個目標（why）而執行的活動（what），對於無業務流程的業務，我們需要從源頭看服務請求，在業務流程識別中圖2-5和圖2-6中指出，無論是外部，內部，還是管理類的流程都有一個發起源頭，對於靜態場景，沒有流程，只需要透過類似方法，識別源頭的服務請求，搞清楚源頭角色對於業務場景本質的幾個要素是什麼，就可以得到業務場景。

在業務場景分析中，我們可以得到多個利益相關者在不同場景的用例，我們也會對不同場景的用例集中去看利益相關者角色的總體產品行為，在使用者角色視角清晰看到他們對產品/系統的訴求。

在Eric Evans 的領域驅動設計中，強調要求團隊在進行所有的交流是都使用一致的語言，在程式碼中也是這樣。這一 “統一語言(Ubiquitous Language)“被非常重要的強調。

統一語言的一個目的是為了有效溝通，在Eric Evans領域驅動設計的統一語言獲取闡述中，透過空中交通監控樣例中開發人員和領域專家之間對話逐步提取語言，現實中基本很難行的通，在實際的日常環境中，領域專家角色不明確，對於領域知識的獲取，會從業務側的支持者，產品經理，研發人員多方的直接或者間接的溝通中獲取，產品經理和業務利益相關者的訪談，研發人員和產品經理的需求評審等形式中獲取，這裡面業務利益相關者，產品經理，研發人員都有自己的語言體系，上述的價值需求和業務需求的一些視覺化的結果產物（業務流程圖/業務用例圖），以及分析方式，都是為了在溝通中捕捉到更完整的領域知識，反覆確認，不斷達成統一語言。

統一語言另一個目的是為了就領域問題，知識達成各個利益相關者的理解一致，最好的方式是有視覺化的圖表，文件描述來確認這些理解，形成統一的認知。例如，在OGV的內容運營側會提到“廠牌”這樣的業務表達，這個概念在產品或者研發側是完全不知道在表達什麼，那麼在需求的溝通和確認過程中，明確“廠牌”就是指媒資的製作或者出品的公司品牌“BBC”、“國家地理”、“迪士尼”這類。理想的統一語言是希望做到業務，產品，技術統一表達製作公司/出品公司，但在實際中，我們無法要求業務的表達做出改變，對於“廠牌”的通俗表達，在技術程式碼中又不太能明確表達，在反覆確認中，統一認識，在統一語言文件中，指明“廠牌”和製作公司/出品公司是同一業務含義。

統一語言的使用和建立貫穿問題探索，需求明確，到模型分析，設計，程式碼的編寫，建議在模型和程式碼之間以及在統一語言和程式碼之間做對映。這非常有幫助，它會讓程式碼更可讀，讓模型得到完美實現。

什麼是領域，為什麼要有子領域，這裡只通俗談自己的理解，領域就是知識的集合，比如提到財務會計領域，自然會聯絡到總賬，利潤，會計科目，固定資產等，這些都是特定財務領域知識。

在OGV業務的整個問題空間中，涉及版權，媒資，劇集，影片，社群，風控，投放，營銷等知識。透過需求分析，將業務流程和業務場景，視覺化的呈現在團隊面前，其實問題本身已經變的清晰。面臨OGV整體的問題空間時,業務複雜度比較高，為了降低關注的業務複雜度，同時讓開發團隊更好把握問題空間，不至於迷失在業務細節中，我們劃分了子領域。

在《實現領域驅動設計》和領域驅動相關社群中都有一些說明，子領域是對問題的分解，對子領域區分：核心子領域，通用子領域，支撐子領域，也是為了區分整個問題空間裡面的重要問題和次要問題，透過劃分子領域，讓相關人員對問題空間本身有共同的理解，也能確定不同業務的優先順序，每個對應子領域該安排有能力的團隊成員來開發，還是次能力團隊成員來開發。一般情況下透過判斷業務價值的大小就可以確認哪些業務屬於核心子領域（核心問題），通用子領域（沒有領域個性），支撐子領域（輔助完成解決核心問題），這裡主要看上面價值需求分析的結果。

那如何識別和區分子領域。通常從以下幾個方面：

1. 透過業務職能劃分，如果系統運用於企業的生產，運營，管理，那麼與系統有關的職能部門職責會影響子領域劃分，職能部門的組織結構和子領域有一定的對映關係，結合圖2-7的業務流程，同時在需求分析中也比較容易得到OGV業務的組織結構，OGV媒資製作，OGV內容運營，版權運營，這些職能角色或者部門在內容生產製作，內容運營，投放運營方面有對應的職能分工。

2. 透過業務產品劃分，最典型的就是企業的產品線或者業務線，比如B站的漫畫業務，電商業務，遊戲業務等，這些業務結構可以作為劃分子領域的參考。

3. 透過業務流程環節劃分，如果考慮這個因素，那麼確定核心業務全景流程，就會非常重要，根據業務流程的時間節點劃分多個業務環節，如圖2-4流程，一個可供使用者觀看的作品的供應和使用者觀看作品的流程就是其中的一個核心業務流程，該業務流程存在多個時間節點環節，內容引入過程涉及的評估，採購，內容生產涉及到劇集，媒資，影片等，運營宣發投放，使用者消費，社群管理，這些環節節點是考慮子領域劃分的重要依據。

4. 透過業務概念進行識別劃分，這個就比較玄學了，主要依靠對問題的深刻分析理解和直覺。對於OGV的業務可以浮現出來的業務概念：版權，劇集，媒資，片單，系列，影片，稿件，彈幕，評論等，根據這些概念找到與之對應的管理這些業務概念的子領域，例如對稿件管理的稿件平臺。

雖然我們可以從上述的一些角度分析劃分子領域，但是這個過程還是存在很多經驗因素，同時在討論過程中還要規避很多容易陷入技術實現的陷阱。作為技術角色參與這個過程一定要分清此時的目的是為了拆分，確認問題領域，切勿考慮如何解，例如我們知道OGV業務中涉及到彈幕，評論，那麼在解空間中我們考慮是否要建立彈幕管理，評論管理，這個實際的建立是直接委託給B站內部UGC業務同樣業務屬性的彈幕中心，還是需要獨立處理一些OGV業務特性，甚至對於一些業務域可以直接購買外部系統。如果一些技術人員無法避免談過多技術實現，可以在這個分析階段將技術人員排除在外。

結合上述的1，3的業務職能部門的具體職能和核心業務流程的流程環節分析，再結合4方法的業務概念羅列，得出下圖4-1是OGV業務核心相關的子領域對映圖：

^圖4-1

在圖4-1中虛線分割部分是子領域，實線分割為限界上下文，原則上識別出來的每個子域只對應一個問題，子域之間是相互獨立的，沒有交叉，沒有包含關係。圖4-1中的子領域是在整個OGV業務的角度進行識別劃分，在這之外還存在一些非強業務相關的推送通知，流程管理，認證驗權等通用子領域。理論上子領域仍然可以被分解，例如我們透過對不同內容運營部門的不同角色對內容的運營階段的需要，將劇集子領域又被分解為劇集內容，排播，策略規則，每個細分的子領域又對應一個該領域內的特定問題。

除了進行子領域的識別和劃分，在問題階段要明確每個子領域核心要解決的問題是什麼，例如：劇集的領域是作為OGV內容載體供使用者消費，需要解決內容的表達載體，管理，排播，運營等問題。在劇集的細分子領域中：

1.劇集內容的表達，就是要解決劇集，分集，片單的內容關係，以及基於內容的上下架等各種管理，以及使用者的消費。

2.細分的排播子領域：主要是用來解決劇集內容的排播計劃，一方面讓支撐運營管理內容的播放計劃，同時讓使用者可以消費到海量內容的播放計劃。

3.策略規則的子領域：主要是面對運營支撐者解決劇集內容在播放控制，分發控制，付費控制等多個業務維度的運營問題。

當我們在定位一個子領域時，會出現其他業務內也存在這樣的問題，例如：版權，OGV業務面臨版權問題，bilibili的其他業務音樂，漫畫等也面臨版權問題，此時在另一個的層面，企業維度來看，這個對於OGV來說的版權子領域，在企業多業務角度，版權領域的定位就會發生變化，其要解決的就不僅僅是OGV業務的版權問題，並且隨著外部環境變化（政策，行業對版權的規範性變化），領域的重要程度也可能變更，但是並不改變子領域在價值歸屬，版權領域作為支撐子領域的價值判斷。

在看待問題域的子領域時不考慮實現問題，例如圖4-1中的稿件，使用者，彈幕，評論對於OGV業務而言是核心業務，但是這些子領域在實際中已經有其他非OGV業務的支撐人員和系統可以解決這些領域的問題。

這篇文章主要介紹領域驅動設計解決軟體核心複雜性的問題空間分析過程和方法，透過利益相關者和商業模式畫布的價值需求分析，業務流程識別、業務場景識別的業務需求分析方法，分析問題空間的業務問題，根據價值需求和業務需求的分析輸出的視覺化結果初步得到統一語言和子領域，達到對複雜軟體開發的問題規模的分解。更通俗簡單的說，只是在明確業務問題和簡化業務問題。

後續會進一步介紹我們根據領域驅動設計理論和社群中領域驅動架構的演進變化，在實際架構中所做的調整，來分析領域驅動設計的架構模式對結構複雜度的解決方式，還會介紹在子領域內對具體的子領域問題的領域設計和編碼，以及分析模式在具體的問題分析中的應用。

[1]EVANS E.領域驅動設計：軟體核心複雜性應對之道.人民郵電出版社.2010

[2]張逸.解構領域驅動設計.人民郵電出版社.2021

[3]MARTIN R C.架構整潔之道.電子工業出版社.2018

[4]VERNON V.實現領域驅動設計.電子工業出版社.2014

[5]FOWLER M.分析模式可複用的物件模型.機械工業出版社.2004

[6]RICHARDSON C.微服務架構設計模式.機械工業出版社.2019

[7]徐鋒.有效需求分析.電子工業出版社.2017

[8]資料模型資源手冊：卷1.機械工業出版社.2009

[9]