编辑导语：在建设中台时，领域划分与需求结构化是相辅相成的，领域划分是为了更好地将需求结构化，需求结构化也有助于领域划分，边界清晰。那么要如何进行领域的划分和需求结构化呢？一起来看一下吧。

之前关于中台的入门介绍写了三篇，讲了中台的规划和能力模型，今天来细说说领域划分与需求结构化。

今天这篇文章主要是讲理论和概念。

领域划分与需求结构化相辅相成，领域划分是为了更好地将需求结构化，需求结构化也有助于领域划分，边界清晰。

但是你可能会问了，需求结构化和领域划分的目的是什么呢。

建设中台希望达到的效果是能够将通用的业务逻辑沉淀为能力，最终实现中台能力的高度可复，可以节省新产品新功能的研发时间，提高研发效率。

而领域划分和需求结构化是有助于中台的搭建与能力的复用性的。至于为什么呢，我们在文章里慢慢解答。

首先了解一下，领域划分和需求结构化的概念，分别是什么东西。

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协议