继上篇《企业系统需求分析—干系人识别与分析》之后开始进入产品详细需求环节，本文主要讲解系统分解中的子系统划分与业务接口分析。

一、划分子系统

我们在对系统进行分解时，无外乎有三种情况。

1⃣️简单的业务系统，用户群比较单一

2⃣️基于原有的系统进行改造

3⃣️新开发的系统

第一类情况由于用户群单一且业务简单，一般不作划分。

第二类情况要注重分析对原有系统的影响。包括需要新增哪些子系统、影响哪些子系统、哪些原有的子系统需要修改等。

这类着重讲下新开发的系统如何进行划分。

内部系统一般采用按业务职能来分解。先画出与系统相关的组织架构图，以此划分出对应的子系统，一般典型的企业都会有产、销、供、管这四个部门职能，对应CRM、ERP系统等等。

外部使用的系统一般采用产品服务来分解。根据业务结构树来思考，切记要从业务的角度去理解。

另外也会根据实际情况来采用业务职能与产品服务两种方式结合起来划分。

划分之后要留意子系统之间、子系统与原有系统之间的接口关系，确认谁服务于谁、谁使用、接口是新增/修改等事项

二、业务接口分析

首先要明确业务接口分析只是明确Why和What，不涉及How。

所谓why就是明确接口的用途与价值。我们需要明确三个问题。

1⃣️那个子系统实现该接口。

2⃣️哪些子系统会用到这个接口，以及各自的业务价值。

3⃣️接口使用的频率范围是什么？尽量具体，如果有场景信息和条件更好，方便研发人员判断。

所谓How就是细化接口交互过程。一般会采用时序图和数据词典来定义与描述。

时序图用于呈现接口的交互过程，而数据词典用于定义交互过程中数据包的构成情况，另外我们要确定接口的设计约束，比如通信协议、原有系统的影响等等。

下篇文章将分享功能需求的业务流程识别、分析与优化的相关知识。

提纲：

划分子系统遵循四个原则的相关：职责、通用性、开发技能、工作量。

协作决定接口。

 

如何划分子系统

下面是分层的细化、分区的引入、机制的提取这3种策略背后的4个通用设计原则：

职责不同的单元划归不同子系统。

通用性不同的单元划归不同子系统。

需要不同开发技能的单元划归不同子系统。

兼顾工作量的相对均衡，进一步切分太大的子系统。

如图13-11所示，子系统的每种划分策略，都是一到多个原则综合作用的结果。

498)this.style.width=498;"
 height=437<

 

接口设计的事实与谬误

世界是复杂的，很多东西难以直接获得。例如，直接追求幸福，是永远追不到的。（《乐在工作》一书中说幸福是副产品。）

殊不知，合理的接口设计也不是"直接"得到的。

由于面向对象非常强调"自治"，许多人不知不觉地形成了一种错误认识：面向对象推崇"我的接口我做主"。很遗憾，"自治"正确，但"我的接口我做主"这个推断是错误的。

软件世界中本无模块。1968年，Dijkstra发表了第1篇关于层次结构的论文《The Structure of THE-multiprogramming System》。1972年，Parnas发表论文《On the criteria To Be Used in Decomposing System into Modules》论及了模块化和信息隐藏的话题……这些是架构学科开始萌芽的标志。

那么，为什么要对软件进行模块化设计呢？是为了解决复杂性更高的大问题。于是，我们突然领悟：对问题进行分解，分别解决小问题，其实这只是手段。每个架构师应牢记：

"分"是手段，"合"是目的。不能"合"在一起支持更高层次功能的模块，又有何用呢？

因此，我们必须把模块放在协作的上下文之中进行考虑。架构师设计接口时，要考虑的重点是"为了实现软件系统的一系列功能，这个软件单元要和其他哪些单元如何协作"，总结成一句话就是：协作决定接口。

相反，直接设计接口，是很多"面向接口的"架构依然拙劣的原因之一。类似"我的接口我做主"的观点是错误的（如图13-12所示），每个模块或子系统（甚至类）无视协作需要而进行的接口定义很难顺畅地被其他模块或子系统使用。




498)this.style.width=498;"
 height=373<  



"世界上最短的距离不是直线"，又多了一个例证。

服务子系统的数量把控

      过多：可能划分过细，破坏业务子系统的独立性（如：支付订单、退款订单，用户、账户）；部署维护工作量大，独立进程占用内存多

      过少：没能很好的解耦；开发维护不好分工；升级维护影响面大

服务子系统划分注意事项

      1、不要出现A服务中的SQL需要链接查询到B服务中的表等情况，这样在A服务与B服务进行垂直拆库时就会出错

      2、服务子系统间避免出现环状的依赖调用

      3、服务子系统间的依赖关系链不要过长

      4、尽量避免分布式事务

Dubbo服务接口的设计原则

      1、接口类型

简单数据查询接口：action、facade、dao
带业务逻辑的数据查询接口：action、facade、biz、dao
简单的数据写入接口：action、facade、dao
带业务逻辑的数据写入接口：action、facade、biz、dao
同步接口
异步接口

       2、接口粒度

服务接口尽可能大粒度，每个服务方法应代表一个功能，而不是某功能的一个步骤，否则将面临分布式事务问题，
Dubbo暂未提供分布式事务支持。同时可以减少系统间的网络交互。
服务接口建议以业务场景为单位划分，并对相近业务做抽象，防止接口数量爆炸。
不建议使用过于抽象的通用接口，如：Map query(Map)，这样的接口没有明确语义，会给后期维护带来不便。

      3、接口版本

每个接口都应定义版本号，为后续不兼容升级提供可能，如：
<dubbo:service interface="com.XxService" version="1.0" />

接口兼容性
服务接口增加方法，或服务模型增加字段，可向后兼容；
删除方法或删除字段，将不兼容，枚举类型新增字段也不兼容，需通过变更版本号升级。


      4、在Provider上尽量多配置Consumer端属性

原因如下：
作服务的提供者，比服务使用方更清楚服务性能参数，如调用的超时时间，合理的重试次数，等等。
在Provider配置后，Consumer不配置则会使用Provider的配置值，即Provider配置可以作为Consumer的缺省值。
否则，Consumer会使用Consumer端的全局设置，这对于Provider不可控的，并且往往是不合理的。
Provider上尽量多配置Consumer端的属性，让Provider实现者一开始就思考Provider服务特点、服务质量的问题。

 

1.服务划分

服务化的目标：
将系统中独立的业务模块抽取出来，按业务的独立性进行垂直划分，抽象出基础服务层。


服务化的目标：



服务化的目标：基础服务为上游业务的功能实现提供支撑，基础服务应用本身无状态，可随着系统的负荷灵活伸缩来提供服务能力。
服务子系统的数量把控
过多：可能划分过细，破坏业务子系统的独立性（如：支付订单、退款订单，用户、账户）部署维护工作量大，独立进程占用内存多

过少：没能很好的解耦开发维护不好分工升级维护影响面大
（以简易版支付系统服务的划分为例）服务子系统划分注意事项：
不要出现A服务中的SQL需要链接查询到B服务中的表等情况，这样在A服务与B服务进行垂直拆库时就会出错。（一旦分库分表就 会出错）


服务子系统间避免出现环状的依赖调用服务子系统间的依赖关系链不要过长尽量避免分布式事务
服务子系统的划分是一个不断优化的过程



2.Dubbo服务接口设计

action、facade、biz、dao
好的Dubbo服务接口设计，并非只是纯粹的接口服务化

2.1接口类型
简单数据查询接口：action、facade、dao
带业务逻辑的数据查询接口：action、facade、biz、dao


简单的数据写入接口：action、facade、dao
带业务逻辑的数据写入接口：action、facade、biz、dao


同步接口异步接口
2.2设计原则接口粒度
服务接口尽可能大粒度，每个服务方法应代表一个功能，而不是某功能的一个步骤，否则将面临分布式事务问题，Dubbo暂未提供分布式事务支持。同时可以减少系统间的网络交互。
服务接口建议以业务场景为单位划分，并对相近业务做抽象，防止接口数量爆炸。
不建议使用过于抽象的通用接口，如：Mapquery(Map)，这样的接口没有明确语义，会给后期维护带来不便。
2.3设计原则接口版本
每个接口都应定义版本号，为后续不兼容升级提供可能，如：
<dubbo:serviceinterface="com.XxService" version="1.0" />
2.4设计原则接口兼容性
服务接口增加方法，或服务模型增加字段，可向后兼容；删除方法或删除字段，将不兼容，枚举类型新增字段也不兼容，需通过变更版本号升级。
2.5设计原则异常处理
建议使用异常汇报错误，而不是返回错误码，异常信息能携带更多信息，以及语义更友好。
如果担心性能问题，在必要时，可以通过override掉异常类的 fillInStackTrace()方法为空方法，使其不拷贝栈信息。
查询方法不建议抛出checked异常，否则调用方在查询时将过多的try...catch，并且不能进行有效处理。
服务提供方不应将DAO或SQL等异常抛给消费方，应在服务实现中对消费方不关心的异常进行包装，否则可能出现消费方无法反序列化相应异常。
2.6设计原则
必要的接口输入参数校验.