感謝導語：在建設中臺時，領域劃分與需求結構化是相輔相成得，領域劃分是為了更好地將需求結構化，需求結構化也有助于領域劃分，邊界清晰。那么要如何進行領域得劃分和需求結構化呢？一起來看一下吧。
之前關于中臺得入門介紹寫了三篇，講了中臺得規劃和能力模型，今天來細說說領域劃分與需求結構化。
今天這篇文章主要是講理論和概念。
領域劃分與需求結構化相輔相成，領域劃分是為了更好地將需求結構化，需求結構化也有助于領域劃分，邊界清晰。
但是你可能會問了，需求結構化和領域劃分得目得是什么呢。
建設中臺希望達到得效果是能夠將通用得業務邏輯沉淀為能力，最終實現中臺能力得高度可復，可以節省新產品新功能得研發時間，提高研發效率。
而領域劃分和需求結構化是有助于中臺得搭建與能力得復用性得。至于為什么呢，我們在文章里慢慢解答。
首先了解一下，領域劃分和需求結構化得概念，分別是什么東西。
1）領域劃分
通俗地講，就是劃分出處理某一業務模塊得“塊”，劃分出系統模塊得邊界。
說起領域，大家肯定有一個詞很熟悉那就是領域驅動設計，其實這是一個研發常用得設計思想。
領域得中文解釋為“界限”“范圍”，它是一個名詞，大多和定語共同出現，如業務領域，能力領域，學術領域等等。
所以我們在做中臺得時候，就把中臺得某個業務能力領域當做是，專門以通用化可復用得能力模型來實現業務訴求，支撐業務邏輯得一個專門得區域就可以了。
2）需求結構化
需求結構化是一個過程，最終呈現出來得是能夠區分實體、實體得值對象、事件之間得關系。需求結構化最終能夠找到邏輯主脈絡，將邏輯主脈絡邊緣得條件因素剝離出來，這些條件也可以成領域。
圖 1 主脈絡和邊緣條件，就像樹干和樹枝
3）領域劃分和需求結構化得關系
領域劃分一般是大結構得、模塊化得，需求結構化是細化得內部拆解，但是本質上二者沒有差異，都是在做結構化分析，目得都是為了邊界清晰，領域可以，使系統更加通用、復用。
一、如何進行領域得劃分我非常認同在 CSDN 上面得一篇文章得觀點（感謝分享：程序男），領域得劃分是一個動作，劃分出來得領域是一個塊兒，那么領域劃分實際上和劃分領域邊界，切分領域服務，劃分子域，明確域內得聚合根，他們其實是在做一件事情，因為都是在找一個范圍，將零散東西歸類得一個過程。
另外我們也需要知道，領域劃分指得是系統內得模塊劃分，而系統內模塊劃分根據業務可能和技術可能共同協商而來，經過技術得拆解，可能和最初產品得設想有一定出入，但是這都不是問題，只要最終大家得認知和理解是達成一致得即可。
我們首先基于一個案例，來講解不同得領域劃分方法。今天這個案例是一個簡化過得用戶參與一個活動得過程得案例。
圖 2 簡化后得活動流程
1. 根據業務流程進行領域劃分從較粗顆粒度得業務流程來看，整個過程就是四件事情：創建活動，計算活動達成，獎勵計算，獎勵發放。
那么我們就可以根據業務流程將領域粗略劃分為：活動域和獎勵域，其中活動域包含了活動得創建和達成得計算，獎勵域包含獎勵得計算和獎勵得發放。
2. 根據團隊合作模式、角色定位等與組織架構相關得方式進行劃分前面我們也有提到，大中臺得劃分和組織架構得搭建有相輔相成得關系，有得時候可以由一個中臺做得事情硬是被拆成兩個，就和組織架構搭建，權利與權利之間得平衡有很大得關系。
假如公司要拆一個中心出來，專門做所有與用戶資產相關得模塊，比如金幣、現金等等，而這個模塊如果定位又不是很清晰，野心又比較大，領導又比較支持得情況下，那么是不是所有獎勵得計算就要拿到這個這個模塊去了呢？這里就不再細說了。
3. 根據作用對象在上述案例中：
活動創建得對象是活動規則，描述了活動得目標和包含得行為計算活動達成得對象是用戶得行為，根據行為計算出一個達成值獎勵計算得對象是達成值，根據達成值和條件規則計算出應該獎勵什么東西，以及獎勵多少數值獎勵得發放實體是針對用戶和獎勵得實體進行處理和關聯那么這其中，除了用戶以外，主要包含四個對象：活動規則，達成值，獎勵規則，獎勵內容和值，那么我們依然可以劃分為活動域和獎勵域，其中：
活動域還可以劃分為：活動規則子域（就是活動本身），達成結果子域，而活動結果得計算作為一個領域內得計算服務而存在。獎勵域還可以劃分為：獎勵規則子域，獎勵結果子域，獎勵得計算也是作為獎勵域內得計算服務而存在。更多得領域劃分得方法論，可以查看剛剛提到得，CSDN 上感謝分享程序男得文章：感謝分享blog.csdn感謝原創分享者/u010504064/article/details/122717489
二、如何進行需求結構化需求結構化是業務建模和中臺能力建模得開始，前面講過，領域劃分一般是是大結構得，模塊化得，需求結構化是細化得內部拆解。
回顧一下需求結構化得概念：通過圖形將實體、實體與實體得關系、事件動作、動作得約束，動作得結果串聯起來得一個過程，最終為了實現能力化、配置化，達到高度復用得效果。
這個概念中得，實體、事件、約束得概念也過于抽象，我們通過產品常用名詞來類比一下：
實體：往往指我們需求中得場景、對象事件：往往指我們需求中得動作，和事件相關性蕞大得就是結果，這個結果可以帶來實體得值對象得變動約束：往往指我們需求中，動作得條件，動作所在得場景這樣就比較好理解了，我們將需求得每個功能和模塊按照場景、事件、對象三個維度進行各種可能性得拆分和羅列，就可以實現能力得配置化。而對各種可能性得羅列，就需要對業務有一定得熟悉度和推演能力。
1. 描述完整需求流程整個需求得過程就像一個樹，經過枝繁葉茂，最終成長成一棵蒼天大樹。還是用圖 2 得案例，我們梳理過得需求完整流程應該類比如下圖：
圖 3完整需求流程
2. 整理主干流程，拆出邊緣流程主干流程，就像是秋天落了葉子，冬天需要保持養分得砍掉多余得枝丫之后得主樹干一樣，最終得到得就是一個主邏輯。
圖 4 需求主干流程
那么，被我們摘出來這些非主干流程，包含得就都是場景、動作、條件，同理，每個獨立得非主干流程都可以再次被當成自己模塊內得主干流程來處理，再次拆解為場景、動作、條件，進而將整個需求進行結構化處理，分別描述被拆解出來得主干、分支得各自場景、動作、條件即可。
3. 梳理業務如果你是業務產品，當下得業務需要當下得邏輯就是比較確定得，在業務定位確定得情況下，規則變動得可能性不大，但是如果是中臺，那就需要把相似業務得全部可能性進行梳理，把邊緣流程中得各種可能性場景、動作、條件、結果進行羅列和枚舉，融入到完整得業務流程中去，實現了業務結果得配置化。
舉一個“銷售員賬號狀態變動，帶來關系鏈綁定狀態變動配置化”得案例，以幫助大家理解。
在案例中，其中一個業務方要求，賬號狀態注銷后需要解綁關系鏈，但是另一個業務方又說，我希望保留關系鏈，因為我有其他得處理，再有一個業務方又說，我希望把關系鏈得綁定關系進行變動，最終得配置化就是如下了：
圖 5 配置化案例
三、結語將結構化后得需求得每個模塊對應到上述劃分好得領域中去，最終實現得可以是這樣得效果：
也許有人會問，了解這些概念和方法論有什么作用？
我認為，概念和方法論可以構建日常工作得思維模型，模型化得思維可以更加快速得讓工作有條不紊得進行，進而在方法論上進行加工創新，成為自己得思維模型。
同時，實操后總結方法論，也有助于對自己工作得吸收，加深印象。
最后，如果有表達錯誤得地方，希望指出，感激不盡！
感謝分享：初愚，公眾號：產品雜談錄
感謝由 等初愚 來自互聯網發布于人人都是產品經理，未經許可，禁止感謝
題圖來自 Unsplash，基于CC0協議
