软件设计不是CRUD（12）：低耦合模块设计理论——业务抽象：模块分层操作

接上文《软件设计不是CRUD（11）：低耦合模块设计理论——业务抽象：规划模块分层》

3、模块的边界

上篇文章的内容基本上说清楚了模块为什么要进行分层设计，以及模块分层设计所遵循的基本原则。本节内容我们就来讨论一下如何实际进行模块的分层规划。前文已经提到，在完成从需求中提取业务维度的工作后，需求中的模块拆解情况只是设计人员基于对原始需求初步的理解、基于自身的工作经验进行的拆解。随着模块分层设计的深入，这些被初步划分的功能模块可能会进行再拆分、再合并、再添加甚至进行删除操作。

既然模块是一组行为和模型的集合，那么模块的边界当然就包括行为边界和模型边界。并且模型边界的确认将对模块边界划分起到决定性作用，行为边界只是模型边界确认后进行模块内功能设计的必然产物。

3.1、模块中的模型边界

业务模型主要是指业务主体和连接这些业务主体的关联信息。业务主体，是功能模块中可以独立进行增删改操作的业务单元。业务主体是一个抽象概念，在不同的场景实现中业务主体的实现情况可能不一样。诸如订单基本信息和订单商品明细信息就是某种场景下订单业务主体的一种典型实现。其它场景下，订单基本信息+订单商品明细+订单物资占用明细又可能是另一种订单业务主体的具体实现。

一个功能模块中一定会有一个业务主体，并且一个功能模块中存在多个业务主体的情况也是有的。例如费用模块中就可能就有两个业务主体：费用类型和费用凭证，两个业务主体（费用类型和费用凭证）可以单独进行维护。这两个业务主体虽然独立进行维护，但绝大多数情况下又需要组合起来构成一个费用模块整体，向外部其它模块提供服务。在外部模块看来，一张单据只要具有费用类型编号和费用凭证编号，就是一张有效的费用单据

关联信息就是描述业务主体之间如何进行关联，这个关联信息可能是描述的两个业务主体如何进行关联，也可能是描述的多个业务主体如何进行关联。也就是说功能模块中要存在两个或者两个以上的业务主体，才会有关联信息。关联信息如果处于模块内，那么说明被关联的两个或者多个业务主体可能存在于同一个功能模块；关联业务模型如果处于模块外，那么说明被关联的两个或者多个业务主体一定不存在于同一个功能模块中。

请不要尝试用关系型数据库中的数据表概念来理解本节描述的业务模型。数据表是一种具体的设计落地形式，而业务模型是业务抽象中对于模块中业务数据的一种抽象表达。如果说两者真的存在什么联系，那么联系仅限于业务模型的一种具体落地实现是数据库中的一张或者多张数据表。数据表和数据表的关联和本节描述的关联模型也不是一个概念，诸如订单数据表和订单商品明细表看似是一种关联信息，但实际上两个表都属于同一个业务主体的一种具体实现形式，并不是主体和主体之间的关联信息。

那么有一个问题就需要进行思考了，当两个业务主体不在一个模块内，那么他们的关联信息应该由哪个模块进行维护？或者换一个更好理解的提问方式：模块A和模块B存在信息关联，那么关联信息应该怎么进行维护？这里有三个选项：

A、关联信息应该放在模块A的边界外，由模块B进行管理
B、关联信息应该放在模块A的边界内，由模块A进行管理
C、应该单独有一个模块C，专门管理关联信息。

首先应该排除选项C，因为前文已经明确描述到：“一个模块中一定会有一个业务主体”，显然模块间的关联信息并不是一个业务主体，所以不可能单独创建模块而仅仅用来管理关联关系。另外，两个业务主体不在一个模块内且两个业务主体又存在关联信息，那么势必导致承载这两个业务主体的功能模块存在关联。两个模块存在关联，势必出现一个模块依赖另一个模块的情况（注意：这种依赖肯定需要杜绝循环依赖的情况）。两个模块存在依赖关系，又势必出现两个模块存在上下层关系。

那么以上的问题还可以进行简化：当模块A和模块B存在信息关联时，那么关联信息应该由上层模块进行维护，还是由下层模块进行维护。回答这个被再次简化的问题，相信对读过本专栏之前内容的读者应该不难。由于模块分层的一个原则就是，上层模块对下层模块透明，而关联信息中明显会包括两个业务主体的关键信息（例如关联的费用类型编号 + 费用凭证编号），所以读者应该能很快得出一个结论：关联信息应该由上层模块进行维护，否则下层模块就需要知晓上层模块的存在，至少是上层模块的某些关系信息的存在。

由上层模块维护关联关系，可以保证上层模块中的各主体模型（的关键信息）不会泄露给下层模块。但这个原则也不是一成不变的，如果设计者能够找到所有关联信息的共性，并保证这个共性在上层模块的任何扩展过程中都保持不变，且都能找到唯一对应的业务信息，那么也可以将基于这个共性的关联信息，交给下层模块进行维护。

例如，订单模块作为上层模块，无论是销售订单的实现、补货订单的实现、赠品订单的实现，其订单信息和发货单的对应，都是通过订单类型 + 订单编号这两个信息作为关联依据的，并且后续无论什么样的订单和发货单关联，也都能且只能通过订单类型 + 订单编号的方式和发货单进行关联。那么这时，订单业务和到货单业务的关联信息，就可以由处于下层的到