软件设计不是CRUD（10）：低耦合模块设计理论——业务抽象：从需求中提取业务维度

接上文《软件设计不是CRUD（9）：低耦合模块设计理论——设计落地所面临的挑战》

2、什么是业务抽象

业务抽象是一种将需求落地成模块功能的设计思想，是对业务需求和技术设计进行转换、隔离的一种分析方法。经过业务抽象后的业务模块一般具有较高的业务屈服度，能更大程度满足模块设计中的基本原则要求。进行业务抽象设计有以下几个关键工作步骤：

• 提取业务维度：业务抽象的一个工作是在需求中提取到变化的业务维度，以及各个业务维度的工作关系。这些业务维度的提取对模块的设计落地至关重要。这些业务维度可能是相互影响的，也可能是独立存在的，但相互影响的场景占大多数情况。

• 确认模块分层：从各个业务模块中提取的业务维度，也是后续确认各个模块所处分层的重要依据。就像上文描述的那样，模块的业务维度自身变化风险越大的模块应该置于应用系统中的更上层；业务维度自身变化风险越小的模块或者与业务无关的工具类型的模块，应该置于应用系统中的更下层。这样的设计目的是保证模块在必须进行设计调整时，调整成本最小。确认模块分层也是后续进行各模块间模型关联性设计、行为关联设计的前提。

• 抽象模型：业务抽象的另一个工作是基于业务维度和确定的模块分层，来定义最小业务模型——满足业务模块的各种模型结构的最大公约数。或者说业务模型之所以能在这个业务模块中工作，其最小应该具备的业务定义。举例来说，各种订单模型之所以能在订单模块中工作，是因为无论哪种订单模型都具有订单类型、订单编号和订单租户这三个业务信息。再例如，租户模块中工作的各种租户信息，都必须具有唯一的租户编号，否则就不认为是租户模型，就不能在租户模块中工作。

• 抽象行为：业务抽象的最后一个工作，是从需求中提取业务模块的关键行为。这些行为分为两种类型：控制逻辑和业务逻辑。业务逻辑是存在于需求场景的各个业务操作点，和之前从需求中提取出来的业务维度紧密相关。例如验证单据正确性、激活通知、发送消息都是独立的业务操作点；控制逻辑是一条或者多条将业务逻辑在各个业务操作点上串联起来的控制方式。好的业务模块设计中，业务逻辑和控制逻辑都可以进行扩展（注：本专题后续文章将重点讲解如何利用设计模式对抽象的行为进行设计落地）。

从上图可知，基于业务抽象进行功能模块设计时，设计目标是完成模型和行为的抽象。为了完成这个设计目标，首先需要从需求中抽取业务维度。本文先来详细介绍第一个话题：如何寻找需求中的业务维度，并进行实例演示。

3、需求中的业务维度

正如上文所描述的那样，业务维度是在业务边界内的可变要素，当业务维度的要素出现不同的值时，会对业务行为产生不同的影响，甚至会分裂出不同的业务走向。提取的每一个业务维度将在随后的设计中形成被控制逻辑管理的一个个关键业务操作点。在以上对于业务维度的描述定义中，读者需要注意几个关键点：

• 在业务边界内的：

进行订单业务模块的需求分析时，能不能将出库单类型提取成一个业务维度呢？很明显这是不行的，因为订单业务模块和出库单业务模块从经验上来讲就是两个不同的模块（绝大多数实际业务场景也是这样的），在设计时他们就应该具有业务隔离性。好的、稳定的分层设计后，订单模块甚至都可能不再知晓有一个出库模块的存在。

有的读者可能会提出质疑，怎么会不行呢？出库单类型万一和订单类型有关呢？例如普通订单生成普通的出库单，赠品补单性质的订单生成补货出库单。两者怎么会没有关联呢？就算需求确实是这样的，库存的处理业务也是在订单业务之外。以上提出的质疑只能说是如何划分业务边界的问题，而不是边界内如何提取业务维度的问题。订单在创建成功后，完全可以通过事件通知、状态通知的方式，将订单已经创建好的状态告知出库模块，再由出库模块自身决定如何进行后续出库业务的处理。换句话说，就是一种模块间行为的关联方式。

• 可以变化的要素：

提取出来的业务维度，其值一定是可变的，并且完成设计后其值也是可扩展的。例如订单类型原始提供了两个值：销售订单、采购订单，这两种订单类型所代表的业务场景是完全不一样。并且这个订单类型维度还可允许二次开发团队进行值的扩展（当然值的扩展也就意味着业务逻辑的扩展）

3.1、业务维度存在的形式

绝大多数情况下，设计人员从需求中提取出来的业务维度都具有一定的关联性，这和业务维度的本身的特点有关：业务维度是需求中可变化的要素，既然是可变化的要素其变化后必然对周围的事物产生或多或少的影响。这种需求的示例可以列举很多，例如：当指挥员身份为资深船长时，才能指挥5万吨以上舰艇作战；只有订单类型为退货订单时，不需要在订单结束后发送短信，改为发送邮件……

业务维度在业务性需求中一定存在且至少有一个，否则业务功能落地后将是一潭死水