如何规划系统的架构

在规划一个信息系统时，常常有很多人一开始就画原型并且做一些主菜单子菜单的划分，这样的方法是存在很大问题的，对系统逻辑的理解只停留在表面。

没错，在设计系统时开始确实是要定义好模块结构的划分，但是划分的方法不应该按照功能模块而是按照业务逻辑进行划分。信息系统只有两个作用，一个是解决问题，另一个是业务提升。首先在规划系统时要思考这个系统的作用到底是解决了什么问题或者对企业带来了怎么样的提升。在这个大的环境下确定了之后，需求分析的阶段，应该按照业务的职责区块来划分子系统。

这张图应该是很普遍而且典型的后台管理系统，但是这样的系统无论是在开发还是使用我认为都是达不到出色的。图中的板块划分采用"业务名词+管理"来进行命名，实际上也就是以"物"为线索贯穿整个系统。但是在实际操作中物与物之间的传递都是交错在一起的，例如图中的项目管理板块中包含了"合同管理"，在合同管理板块中又包含了"合同管理"那么究竟是哪个进行管理呢，项目管理中是否又包含权限的区分呢，这样的划分明显是有问题的。我在另一个回答上提到过"穷尽不重复"的划分方法，其实在这里就可以体现出作用来。

那么正确的后台划分子系统的方式应该是按照业务流程来划分，以"事"为线索贯穿系统。采用业务流程的环节进行划分可以有效的避免重复和混乱的现象，对整个系统的架构都是非常清晰明了的。想要以"事"为线索进行梳理，有一个很好的方法就是使用UML中的构件图的来解决。对于产品人员，只需要理解构件图的思想，画出一个轻量级的框架。

首先在构件图中两个重要的概念构件和接口对应着事件和流程，接口与接口之间只存在实现(代表这个流程由这个事件提供的)和使用(代表这个事件要使用这个流程)这两个关系。理解了这一概念之后就可以对事与事，事与流程，流程与流程之间进行连接。

画构件图，步是识别建模的构建集合，也就是对主题域进行划分。可以按照工作职责范围(部门)划分成不同的主题域，划分的时候也可以根据需要进行多级的嵌套，这样可以更容易理解上下级之间的关联。例如软件开发商可以按照开发人员，产品人员，销售人员职责不同进行级区块划分，然后再根据开发人员负责的不同环节进行第二级部门的划分。那么根据区块就可以很容易划分出"销售"和"研发"两个主题域。

在研发这个主题域内主要负责针对软件研发进行管理，经过设计，研发，测试这几个阶段生产出成型的软件。那么这块就可以命名为"研发管理系统子系统"。

在销售这个主题域内主要负责对客户的销售，客户培训，售后服务等，因此这块可以命名为"客户服务管理子系统"。

在一般的系统中往往会加入后勤板块，在这个板块内含有硬件，财政和人员这些基本模板，可以划分成“硬件服务管理子系统”，"财政管理子系统"和"人员管理子系统"。后面两个子系统按照范围界定的原则相对独立，所以在前期设计中暂不考虑。

第二步需要把功能不同的模块划分成构件，同时确定构件与构件之间的接口，也就是开始绘制构件图。首先每一个主题域就是一个构件，这个比较好理解。先分析各个主题域之间的关系，四个系统两两之间有不同的关系。因为人员管理子系统相对比较独立，所以这块可以后考虑。

"研发管理系统子系统"与"客户服务管理子系统":研发管理需要获取客户服务管理中的订单详情、研发要求、客户资料等；而客户服务管理需要获取研发管理中的项目进展、功能设置等。

"研发管理系统子系统"与"硬件服务管理子系统":研发管理需要知道数据库和服务器的情况，后台资源占用的情况；硬件服务管理需要获取研发团队的项目进度，功能规划和版本维护的情况。

"客户服务管理子系统"与"硬件服务管理子系统": 硬件服务管理需要知道客户的基本信息以便确定投入什么硬件支持；客户服务管理系统一般就不需要从后台服务系统获取信息。

（上图是一个比较简单的原型，实际规划还要考虑主题域之间更多关联）

后一步进行主题域范围的明确，界定每个主题域内进行的功能以及相关的事件。在一些书籍中也把这个关系成为上下文关系，即主题域与功能之间父级与子级的概念。在这个阶段要考虑到Customer与Worker之间的关系。找到系统中所有的客户，考虑这些客户会引起什么事件的发生，这些事件会引起Worker什么样的工作，讲这些都考虑进来。然后再补充Worker主动发起的动作，那么一个系统的所有事件就能没有遗漏地梳理完整了。这里值得注意的是，对于研发管理子系统而言，其他的客服管理，财政管理都属于是客户关系。他们对于研发关系系统属于消费者的动作。

通过以上三步可以把一个系统大致的框架搭建起来。这样搭建的好处在于系统的业务流程很清晰，无论是对于研发还是使用者而言都是有好处的，每个人都能清楚地意识到自己在做什么事情。上述分析方法是徐峰老师提出的SERU需求分析法中关于主题域确定，也就是系统框架结构确定的步，这也是设计一个系统根基的地方，然后才是去考虑更细化，更精准的业务流程设计。把根基打好再去做子系统内部的规划就变得比较简单。对于一个系统，在设计时一定要有“自上而下”的思想，从大的环境去考虑问题，这样才不会在后期规划中因为突然插入的东西变得混乱。(图片有部分来自网络，侵删)