项目开发之职责分离

职责分离分析

项目开发的关键问题是，减少整体风险，让整个项目得以完成。清晰的职责分离带来的是清晰的模块划分，进而可以组合各个模块，将风险降低到各个模块中去。没有良好的职责分离，一个项目将会在出现问题的是让人不知所措，风险将会是整体的风险。

上图对比职责分离与非职责分离的两种结构。通过图形可以直观地得到以下对比：

 职责分离非职责分离备注系统风险低高职责分离后，出现问题，可以定位到模块，并且可以替换模块开发效率高低职责分离后，可以对单个模块进行测试，保证各个模块的正确性
非职责分离方式，需要完全开发完之后才能测试，一旦出现问题需要在整个系统中查找问题可复用可以不可以职责分离后，可以重复使用已经开发的模块可维护容易难职责分离后，可以在已有模块上增加、替换模块，同时不影响原有模块可管理容易难职责分离后，可以及时了解项目的细节
非职责分离，要等到项目完全做完才能管理

在现实开发中，一般不会做完全不职责分离的项目，大多数人都会去对项目划分模块。但这种模块划分往往是无意识的，多数是跟着自己的喜好去划分。最终划分出来的模块与模块之间往往就是铁板一块，没有达到职责分离的目的。

以下介绍职责分离的使用场合及如何进行职责分离。

使用场合

职责分离的使用场合很广泛，几乎遍及到所有行业。在需要分解庞大的或者复杂的问题的时候，或者需要将问题简单化的时候，都需要使用职责分离。举例如下：

软件的分层

软件一般可以分为 MVC 三层（模型-视图-控制），复杂的软件还可以分为 视图-控制-服务-业务逻辑-集成-持久 等层。

• 视图层(V)：负责将数据以用户可以接受的方式展示，用户可以在视图层上对数据进行操作（如修改）
• 控制层(C)：负责将模型层的数据组装好传给视图，也负责将视图的数据封装好传给模型。
• 服务层/模型层(M)：负责处理用户的数据，或者提供用户需要的数据。
• 业务逻辑层：负责处理一个专业的领域的业务逻辑。
• 集成层：为不同的数据源或者服务提供统一的接口，方便业务逻辑层调用
• 持久层，负责将数据持久化。

软件的分层属于将庞大的问题或者复杂的问题分解。

阴阳分类

最简单的分类就是阴阳分类法了。好与坏，男与女，强与弱等，都是这样的分类。通过这样简单的分类就可以将问题理解得更加透彻。从而简化问题。

接口是分离的关键

在职责分离的操作过程中，关键的问题就是划分好界限，明确各个部分之间的不同及相互联系。如软件的 MVC 三层，M 层提供数据，处理数据的业务；V 层展示数据；C 层负责，将用户数据传到 M 层，和，将 M 层数据传到 V 层。明确这三层的区别，在写代码的时候，就不要将三层的职责混淆起来。如，用户输入的数据有问题，应该在哪个地方判断？这个问题显多数情况下需要在 M 层判断，V 层只能辅助判断。因为，只有 M 层才能保证 M 层的正确性，M 层不能依赖于其它层来保证其正确性。

当明确了各个部分的功用之后，就有了各个部分内在的实现及对外的接口。接口是职责分离的关键。能够把各个部分的接口区分开来，才能够真正意义上做好职责分离。

注意问题

职责分离将各个模块分离，同时还需要注意各个模块的配合，各个模块自身相互独立，但能够有效地配合形成一个整体从而提供功能。职责分离是一个从整体到部分，再从部分到整体的过程。在进行职责分离时，往往有会下列情况出现：

• 只单纯分离，而不注重分离之后整体的效果
• 只凭感觉进行分离，分离出来的各个部分没有实际可用性

分离具有多样性，如对人的分类，可以分为好人，坏人；男人，女人等。在实际分离是，需要针对实际问题进行分离。