中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

編輯導語：在建設中臺時，領域劃分與需求結構化是相輔相成的，領域劃分是為了更好地將需求結構化，需求結構化也有助于領域劃分，邊界清晰。那么要如何進行領域的劃分和需求結構化呢？一起來看一下吧。

之前關于中臺的入門介紹寫了三篇，講了中臺的規劃和能力模型，今天來細說說領域劃分與需求結構化。

今天這篇文章主要是講理論和概念。

領域劃分與需求結構化相輔相成，領域劃分是為了更好地將需求結構化，需求結構化也有助于領域劃分，邊界清晰。

但是你可能會問了，需求結構化和領域劃分的目的是什么呢。

建設中臺希望達到的效果是能夠將通用的業務邏輯沉淀為能力，最終實現中臺能力的高度可復，可以節省新產品新功能的研發時間，提高研發效率。

而領域劃分和需求結構化是有助于中臺的搭建與能力的復用性的。至于為什么呢，我們在文章里慢慢解答。

首先了解一下，領域劃分和需求結構化的概念，分別是什么東西。

1）領域劃分

通俗地講，就是劃分出處理某一業務模塊的“塊”，劃分出系統模塊的邊界。

說起領域，大家肯定有一個詞很熟悉那就是領域驅動設計，其實這是一個研發常用的設計思想。

領域的中文解釋為“界限”“范圍”，它是一個名詞，大多和定語共同出現，如業務領域，能力領域，學術領域等等。

所以我們在做中臺的時候，就把中臺的某個業務能力領域當做是，專門以通用化可復用的能力模型來實現業務訴求，支撐業務邏輯的一個專門的區域就可以了。

2）需求結構化

需求結構化是一個過程，最終呈現出來的是能夠區分實體、實體的值對象、事件之間的關系。需求結構化最終能夠找到邏輯主脈絡，將邏輯主脈絡邊緣的條件因素剝離出來，這些條件也可以成領域。

圖 1 主脈絡和邊緣條件，就像樹干和樹枝

3）領域劃分和需求結構化的關系

領域劃分一般是大結構的、模塊化的，需求結構化是細化的內部拆解，但是本質上二者沒有差異，都是在做結構化分析，目的都是為了邊界清晰，領域專業，使系統更加通用、復用。

一、如何進行領域的劃分

我非常認同在 CSDN 上面的一篇文章的觀點（作者：程序男），領域的劃分是一個動作，劃分出來的領域是一個塊兒，那么領域劃分實際上和劃分領域邊界，切分領域服務，劃分子域，明確域內的聚合根，他們其實是在做一件事情，因為都是在找一個范圍，將零散東西歸類的一個過程。

另外我們也需要知道，領域劃分指的是系統內的模塊劃分，而系統內模塊劃分根據業務專家和技術專家共同協商而來，經過技術的拆解，可能和最初產品的設想有一定出入，但是這都不是問題，只要最終大家的認知和理解是達成一致的即可。

我們首先基于一個案例，來講解不同的領域劃分方法。今天這個案例是一個簡化過的用戶參與一個活動的過程的案例。

圖 2 簡化后的活動流程

1. 根據業務流程進行領域劃分

從較粗顆粒度的業務流程來看，整個過程就是四件事情：創建活動，計算活動達成，獎勵計算，獎勵發放。

那么我們就可以根據業務流程將領域粗略劃分為：活動域和獎勵域，其中活動域包含了活動的創建和達成的計算，獎勵域包含獎勵的計算和獎勵的發放。

2. 根據團隊合作模式、角色定位等與組織架構相關的方式進行劃分

前面我們也有提到，大中臺的劃分和組織架構的搭建有相輔相成的關系，有的時候可以由一個中臺做的事情硬是被拆成兩個，就和組織架構搭建，權利與權利之間的平衡有很大的關系。

假如公司要拆一個中心出來，專門做所有與用戶資產相關的模塊，比如金幣、現金等等，而這個模塊如果定位又不是很清晰，野心又比較大，領導又比較支持的情況下，那么是不是所有獎勵的計算就要拿到這個這個模塊去了呢？這里就不再細說了。

3. 根據作用對象

在上述案例中：

• 活動創建的對象是活動規則，描述了活動的目標和包含的行為
• 計算活動達成的對象是用戶的行為，根據行為計算出一個達成值
• 獎勵計算的對象是達成值，根據達成值和條件規則計算出應該獎勵什么東西，以及獎勵多少數值
• 獎勵的發放實體是針對用戶和獎勵的實體進行處理和關聯

那么這其中，除了用戶以外，主要包含四個對象：活動規則，達成值，獎勵規則，獎勵內容和值，那么我們依然可以劃分為活動域和獎勵域，其中：

• 活動域還可以劃分為：活動規則子域（就是活動本身），達成結果子域，而活動結果的計算作為一個領域內的計算服務而存在。
• 獎勵域還可以劃分為：獎勵規則子域，獎勵結果子域，獎勵的計算也是作為獎勵域內的計算服務而存在。

更多的領域劃分的方法論，可以查看剛剛提到的，CSDN 上作者程序男的文章：https://blog.csdn.net/u010504064/article/details/122717489

二、如何進行需求結構化

需求結構化是業務建模和中臺能力建模的開始，前面講過，領域劃分一般是是大結構的，模塊化的，需求結構化是細化的內部拆解。

回顧一下需求結構化的概念：通過圖形將實體、實體與實體的關系、事件動作、動作的約束，動作的結果串聯起來的一個過程，最終為了實現能力化、配置化，達到高度復用的效果。

這個概念中的，實體、事件、約束的概念也過于抽象，我們通過產品常用名詞來類比一下：

• 實體：往往指我們需求中的場景、對象
• 事件：往往指我們需求中的動作，和事件相關性最大的就是結果，這個結果可以帶來實體的值對象的變動
• 約束：往往指我們需求中，動作的條件，動作所在的場景

這樣就比較好理解了，我們將需求的每個功能和模塊按照場景、事件、對象三個維度進行各種可能性的拆分和羅列，就可以實現能力的配置化。而對各種可能性的羅列，就需要對業務有一定的熟悉度和推演能力。

1. 描述完整需求流程

整個需求的過程就像一個樹，經過枝繁葉茂，最終成長成一棵蒼天大樹。還是用圖 2 的案例，我們梳理過的需求完整流程應該類比如下圖：

圖 3完整需求流程

2. 整理主干流程，拆出邊緣流程

主干流程，就像是秋天落了葉子，冬天需要保持養分的砍掉多余的枝丫之后的主樹干一樣，最終得到的就是一個主邏輯。

圖 4 需求主干流程

那么，被我們摘出來這些非主干流程，包含的就都是場景、動作、條件，同理，每個獨立的非主干流程都可以再次被當成自己模塊內的主干流程來處理，再次拆解為場景、動作、條件，進而將整個需求進行結構化處理，分別描述被拆解出來的主干、分支的各自場景、動作、條件即可。

3. 梳理業務

如果你是業務產品，當下的業務需要當下的邏輯就是比較確定的，在業務定位確定的情況下，規則變動的可能性不大，但是如果是中臺，那就需要把相似業務的全部可能性進行梳理，把邊緣流程中的各種可能性場景、動作、條件、結果進行羅列和枚舉，融入到完整的業務流程中去，實現了業務結果的配置化。

舉一個“銷售員賬號狀態變動，帶來關系鏈綁定狀態變動配置化”的案例，以輔助大家理解。

在案例中，其中一個業務方要求，賬號狀態注銷后需要解綁關系鏈，但是另一個業務方又說，我希望保留關系鏈，因為我有其他的處理，再有一個業務方又說，我希望把關系鏈的綁定關系進行變動，最終的配置化就是如下了：

圖 5 配置化案例

三、結語

將結構化后的需求的每個模塊對應到上述劃分好的領域中去，最終實現的可以是這樣的效果：

也許有人會問，了解這些概念和方法論有什么作用？

我認為，概念和方法論可以構建日常工作的思維模型，模型化的思維可以更加快速的讓工作有條不紊的進行，進而在方法論上進行加工創新，成為自己的思維模型。

同時，實操后總結方法論，也有助于對自己工作的吸收，加深印象。

最后，如果有表達錯誤的地方，希望指出，感激不盡！

作者：初愚，公眾號：產品雜談錄

本文由 @初愚 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于CC0協議