子系统划分的误区

对于习惯结构化程序设计的朋友来说，分析设计一个软件的起点是从子系统的划分开始的。而划分的依据一般都是以用户部门或业务进行划分。比如财务子系统、人力资源管理子系统等。但是上面的这些划分均是按用户业务划分的。计算机软件是为了解决现实问题而设计的，现实世界和计算机系统之间并不是相等的关系。因此这种按用户业务划分的方法，对计算机系统来说并没有什么意义。不仅无法有效指导设计和开发，还容易导致系统依赖关系的混乱。
我们现在做的是计算机系统，子系统是针对计算机而言的。划分出来的子系统一定要有利于软件的设计和开发，而不是一味的迎合业务或用户习惯。
业务子系统和计算机子系统是两回事。计算机子系统用来描述一个软件的内部构成，对象依赖问题是主要的划分依据。而业务子系统只是软件的展现形式。用户看到的子系统只是由ui展现出来的样子，软件内部不一定是按照这个划分的。用户所谓的子系统只是软件展现出来的样子。从面向对象的观点来看，软件内部应当维持最佳的对象结构，然后通过接口向外部展现外部所需要的样子。
按用户业务划分子系统最容易导致的问题是数据依赖问题。强制按用户业务或部门、组织划分子系统，可能会导致多个子系统之间的对象依赖。更合理的方式是在划分时将耦合度或聚合度较高的类组织成子系统，沿着弱耦合的边界将类分开，使得每个子系统具有内聚度更高的职责。面向对象要解决的问题是复用、扩展和抽象。这些问题的解决都要建立在高内聚、低耦合的对象基础之上，而只有保持了子系统间的低耦合性才能保证我们拥有独立开发子系统、独立修改和扩展以及独立部署子系统的能力。

摘自：https://blog.csdn.net/ithzhang/article/details/51732088