中小型研发团队架构实践：如何规范公司所有应用分层？-InfoQ



 写点什么

一、写在前面

应用分层这件事情看起来很简单，但每个程序员都有自己的一套，哪怕是初学者。如何让一家公司的几百个应用采用统一的分层结构，并得到大部分程序员的认同呢？这可不是件简单的事情，接下来以我们真实案例与大家一起探讨，先问大家两个技术问题：

服务的调用代码你觉得放到哪一层好呢？

A 表现层
B 业务逻辑层
C 数据层
D 公共层

如何组织好 VO(View Object 视图对象)、BO(Business Object 业务对象)、DO(Data Object 数据对象)、DTO(Data Transfer Object 数据传输对象) 呢？

不同的人会有不同的答案，所以要统一公司应用分层，以减少开发维护学习成本。统一应用分层要可大可小、简单易用、支持多种场景，我们采用 IPO 方式：I 是 Input、O 是 Output、P 是 Process，一进一出一处理。应用系统的本质是机器，是处理设备，一进一出一处理。

IPO 原理图

二、统一逻辑架构

统一应用分层的逻辑架构图

职责说明：

文件夹分层法：应用分层采用文件夹方式的优点是可大可小、简单易用、统一规范，可以包括 5 个项目，也可以包括 50 个项目，以满足所有业务应用的多种不同场景；
调用规约：在开发过程中，需要遵循分层架构的约束，禁止跨层次的调用；
下层为上层服务：以用户为中心，以目标为导向。上层（业务逻辑层）需要什么，下层（数据访问层）提供什么，而不是下层（数据访问层）有什么，就向上层（业务逻辑层）提供什么；
实体层规约：DO 是数据表对象，不是数据访问层对象，不是只能给数据访问层使用；DTO 是网络传输对象，不是表现层对象，不是只能给表现层使用；BO 是内存计算逻辑对象，不是业务逻辑层对象，不是只能给业务逻辑层使用。如果仅限定在本层访问，则导致单个应用内大量没有价值的对象转换。以用户为中心来设计实体类，可以减少无价值重复对象和无用转换；
U 型访问：下行时表现层是 Input，业务逻辑层是 Process，数据访问层是 Output。上行时数据访问层是 Input，业务逻辑层是 Process, 表现层就 Output。

三、我们的具体规范

此规范我们用了四年，牵涉几百个应用，200 多个研发人员，是一个成功的实践。接下来就借用本文提供下载的 TripOrderService、TripSellerMVCSite 这两个 Demo 来进行具体规范的说明，以下是截图：

3.1、项目命名规则

项目命名规则：{产品线英文名全称}.{子系统英文名全称 + 应用名}.{项目职责英文名全称}，如：Trip.Seller.DTO。

3.2、业务逻辑层的项目规范

规范说明：

1、项目名的命名规则：{产品线英文名全称}.{子系统英文名全称 + 应用名}.xxxBusiness，如上图的 Trip.Order.Business。
2、类名以 Logic 结尾，如上图的 OrderLogic.cs。

3.3、数据操作项目规范

规范说明：

1、各数据操作项目名根据使用什么数据库进行分类，然后以 DB 为结尾，具体命名规则是：{产品线英文名全称}.{子系统英文名全称 + 应用名}.{使用什么数据库}DB，如上图的 Trip.Seller.MSSQLDB。
2、如果涉及到多个数据库访问的，那么数据操作项目下的类文件需要按数据库名称（以 DB 为结尾）创建文件夹分开，如上图的 TripOrderDB 文件夹。
3、建议在应用中使用 SQL 语句，不使用存储过程。在数据库中不新增存储过程，但旧的存储过程可以继续使用和修改。
4、分页建议使用数据库（如 SQLServer）的最新特性进行分页，并将每个分页 SQL 直接写到应用中。

3.4、实体类项目规范

数据传输对象 DTO 规范

规范说明：

1、DTO 项目命名规则：{产品线英文名全称}.{子系统英文名全称 + 应用名}.DTO，如上图的 Trip.Order.DTO。
2、请求参数 DTO 实体类、响应 DTO 实体类存放规范以及其命名规则：
- a、请求参数 DTO 实体类放在 Request 文件夹下，且命名规则为：以 Request 结尾，如上图的 SearchOrderRequest.cs。
- b、响应 DTO 实体类放在 Response 文件夹下，且命名规则为：以 Response 结尾，如上图的 SearchOrderResponse.cs。
- c、如果请求参数 DTO 实体类或响应 DTO 实体类的属性中有对象或枚举，那么这些对象所属的类、枚举放在 DTO 项目的 Common 文件夹下。
3、如果请求参数 DTO 实体类、响应 DTO 实体类有基类要继承，那么建议为基类取名为 RequestBase.cs、ResponseBase.cs。且这些基类直接放在 DTO 项目的 Common 文件夹下。

视图对象 VO 规范

规范说明：

1、VO 项目命名规则：{产品线英文名全称}.{子系统英文名全称 + 应用名}.ViewModel，如上图的 Trip.Seller.ViewModel。
2、各 VO 实体类，我们用 Controller 名作为文件夹名进行分开，如上图的 Order 文件夹。
3、VO 实体类名的命名建议：
- a、请求参数 VO 实体类以 Input/Form/Query 结尾，如上图的 SearchOrderInput.cs。
- b、响应 VO 实体类以 Output/List/Result 结尾，如上图的 SearchOrderOutput.cs。

业务对象 BO 规范（可选）

BO 实体类名以 Model 为结尾：

规范说明：

1、BO 项目命名规则：{产品线英文名全称}.{子系统英文名全称 + 应用名}.BO，如上图的 Trip.Order.BO;
2、以 Model 结尾，如上图的 OrderModel.cs；
3、为了简化设计，BO 项目为可选，可在 DO 项目里建文件夹。

数据对象 DO 规范（可选）

规范说明：

1、DO 项目命名规则：{产品线英文名全称}.{子系统英文名全称 + 应用名}.Entity，如上图的 Trip.Seller.Entity；
2、如果涉及到多个数据库访问的，那么需要按数据库名称（以 DB 为结尾）创建文件夹分开，如上图的 TripOrderDB 文件夹；
3、表名 +Entity 结尾，如上图的 OrderEntity.cs；
4、DO 是数据表对象，供单表 CURD 操作。对于多表查询请求对象和返回对象，可定义新对象或使用现有对象（DTO/BO）来完成。

3.5、数据库连接配置规范

规范说明：

1、数据库连接的配置必须读写分离。
2、数据库连接字符串建议加密处理。
3、数据库连接配置名的命名规则：{以 DB 为结尾的数据库名称}_ 读写类型，如：TripOrderDB_SELECT、TripOrderDB_INSERT。

3.6、配置文件方面的规范

规范说明：

1、所有配置文件（除 Web.config 文件外）都必须放到 Config 文件夹下。
2、所有配置文件（除 Web.config 文件外）按不同环境区分开，具体命名规则是：{功能模块英文名}.{环境英文简称名}.config，其中本地环境的英文简称名是 Dev，测试环境的英文简称名是 Test，正式环境的英文简称名是 Prod，如上图的 AppSetting.Dev.config。
3、保持 Web.config 配置文件的干净，只留环境设置节点。

3.7、静态资源文件方面的规范

规范说明：

1、公共的静态资源文件（css、js、image 等）放在另外的静态站点中，统一由前端进行开发和维护。一般，css 文件放在 css 文件夹下，js 文件放在 js 文件夹下，image 图片文件放在 img 文件夹下。
2、与某项业务有关的 js 文件可以放到各自业务项目的表现层 PresentationLayer 下，以方便开发人员调试，js 文件可放在项目的 js 文件夹下。
3、静态资源文件必须使用版本号管理，以防更新后由于客户端浏览器缓存而导致站点使用的依然是旧版本的静态资源文件：

四、写在最后

4.1、问题回答

问：服务的调用代码应该放到哪一层呢？A 表现层、B 业务逻辑层、C 数据层、D 公共层。

我们的规范是统一放到数据资源访问层即 C。上层提供服务，下层调用服务，中间处理业务逻辑。

问：如何组织好 VO(View Object 视图对象)、BO(Business Object 业务对象)、DO(Data Object 数据对象)、DTO(Data Transfer Object 数据传输对象) 呢？

通常有两种做法，限定访问范围和不限定访问范围，实际项目中可根据需要选择、折中或裁剪。我们使用后者，将 EntityLayer 作为通用对象放到左侧，具体可参考实体层规约：

“DO 是数据表对象，不是数据访问层对象，不是只能给数据访问层使用；DTO 是网络传输对象，不是表现层对象，不是只能给表现层使用；BO 是内存计算逻辑对象，不是业务逻辑层对象，不是只能给业务逻辑层使用。如果仅限定在本层访问，则导致单个应用内大量没有价值的对象转换。以用户为中心来设计实体类，可以减少无价值重复对象和无用转换。”

问：应用分层范例代码的编写需要注意些什么？

应用分层范例的代码要想写好，非常不容易，很容易引起争议，很难让所有人满意。我们在具体实践时遵循以下几点：

应用分层范例的主要价值是明确层的职责和交互，每个层的职责是什么，哪些要干，哪些不要干，以及层与层之间依赖和交互；

私人定制：减少通用帮助类的编写，如果每一个应用中有大量相同的帮助类，这在架构层面上是有问题。在我们的几百个线上应用中，尽管减少通用的代码，包括分页帮助类、数据库帮助类、缓存帮助类、MQ 帮助类、日志帮助类、AOP 帮助类、线程帮助类。业务应用的重点是为业务服务，每一个应用都是特别的，都需要私人定制，极少有通用的代码，如果有，那么应该由框架或组件专门解决；

少即是多：应用的场景多，参考人员多，每个人想法不同，牵涉的时间长，所以尽量只做大家都认同的规范、正确的事情，要自底向上、要减少有争议的代码范例，否则一个错误将会放大百倍、一个有争议的规范将会很难推行。

追求简单：代码编写可分为三个层次，简单、复杂、简单。第一简单是不知道的简单，第二个复杂是知道后的复杂，第三个简单是知道后有取舍的简单。范例代码要追求简单，既可轻松扩展支持复杂场景，又要简单到初级程序员也能操作。

内聚大于解耦：内聚是什么，内聚是部门内有共同的目标，然后大家紧密合作。解耦是什么，解耦是部门间各自职责明确，然后减少不必要的连接。一个应用如同一个部门，应有一个共同的目标和职责，然后大家紧密合作。

换句话说，应用内部应减少不必要契约接口（如同公司间才签约合同），减少不必要的依赖注入实现，减少不必要且代价过大的解耦。一切以简单实用为主，以应用价值输出、应用的目标（接口或界面）为导向。