在软件工程中，面对一个复杂系统，我们常常需要划分业务子系统。但很多人容易陷入一个误区：为了划分而划分。其实，划分业务子系统不是目的，而是一种手段，一种控制复杂度的手段。如果系统涉及的业务简单、用户群单一，那就没必要划分。硬拆只会增加集成成本、沟通成本，得不偿失。
那么，需要划分时，该采用什么策略？对于相对复杂的新开发系统，最常用的策略有四种：按业务职能分解、按产品/服务分解、职能/服务双维度划分、按关键特性分解。而对于基于遗留系统开发的系统，则不建议全面转向业务角度划分，更合适的方法是分析新增、修改、影响的子系统。
一、新系统：四种常用划分策略
1. 按业务职能分解
这是最典型的策略，尤其适合支撑、管理业务的系统。部门职能最典型的就是产、销、供、管。划分前，先画出与系统有关的组织架构图，然后根据组织、部门之间的相近度，划分出各个业务子系统。
比如开发一套ERP系统，可以按采购、生产、销售、库存、财务等职能划分。每个子系统对应一个或多个部门，职责清晰，边界明确。
2. 按产品/服务分解
开发“外部服务系统”时，可以先梳理出“业务结构树”，然后以不同的产品/服务作为划分线索。比如银行系统，可以按储蓄、贷款、理财、信用卡等产品划分。医院管理系统，可以按门诊、住院、体检等服务划分。
这种策略也适用于某些“内部管理系统”，只要产品/服务线足够清晰。
3. 职能/服务双维度划分
对于一些更复杂的系统，单一维度不够用，可以采用“职能”和“产品/服务”双维度。先用一个维度做一级划分，再用另一个维度做二级划分。
例如大型综合性医院的管理系统，先用“产品/服务”划分成门诊、住院、体检等子系统，然后使用“职能”对每个子系统做二级划分，如门诊下面再分挂号、收费、药房、医生站等。这样既照顾了业务线，又照顾了职能线，复杂度被有效控制。
4. 按关键特性分解
如果待开发的系统偏向“计算机域”的主题，那就需要换一种策略——按关键特性分解。比如安防系统、楼宇自动化控制系统。简单说，就是从系统对用户的价值角度识别关键特性，然后逐一做后续的需求分析。安防系统可以按视频监控、门禁管理、报警联动、电子巡更等特性划分。每个特性独立分析，最后集成。
二、遗留系统改造：别推倒重来
现在很多系统是基于原有系统的改造和升级，存在大量遗留系统。如果完全按照业务角度重新划分，还将与遗留系统做二次映射，工作量巨大，风险也高。
更合适的方法是直接分析：新增哪些子系统、修改（源代码级）哪些子系统、影响哪些子系统（只需通过配置、加接口实现）即可。这样既尊重了遗留系统的现状，又控制了改造范围。
比如一个老旧的财务系统升级，不必重新按业务职能划分所有模块，只需分析：新增电子发票子系统，修改报表模块源代码，影响与税务系统的接口。清晰明了，改动可控。
三、推广：需求分解也适用
上面讲述的几种对待开发系统的分解方法，虽然面向的是信息系统，但本质上是一种系统分解方法，可以适当地推广到对用户需求分解、对待开发系统分解等应用场景上。
比如用户提出一大堆需求，可以按业务职能分解，也可以按产品/服务分解，还可以按关键特性分解。分而治之，逐个击破，需求分析就不再是一团乱麻。
总结
划分业务子系统是控制复杂度的手段，不是目的。简单系统不必分；复杂新系统按职能、产品/服务、双维度或关键特性分；遗留系统改造直接分析新增、修改、影响。方法得当，事半功倍。
最后，四句诗总结：
系统分解控复杂，简单单一莫强拆。
职能产品双维度，遗留改造辨新增。
参考书目：有效需求分析 ，作者： 徐锋，出版社： 电子工业出版社
