Springboot项目架构设计
导航
- 前言
- 流水线
- 架构的艺术
- 项目架构
- 理解阿里应用分层架构
- superblog项目架构
- 结语
- 参考
本节是《Spring Boot 实战纪实》的第7篇,感谢您的阅读,预计阅读时长3min。 智客工坊出品必属精品。
前言
关于架构的理解,一千个人心中有一千个哈姆莱特。这和项目经验和团队文化有很大关系。
我想很多人其实对编程是有误解的。在中国古代提倡六艺,后面又提倡琴棋书画,这些都是才艺或者技艺。编程也是一门技艺,并没有大家想象的那么神秘。当我们通过书本学到一门编程语言的时候,往往只是学到了一些技巧,一些技术,但是要真正的成为行家,大拿,那就需要艺术了。在编程中,架构就是一门艺术。
流水线
1769年，英国人乔赛亚·韦奇伍德开办埃特鲁利亚陶瓷工厂，在场内实行精细的劳动分工，他把原来由一个人从头到尾完成的制陶流程分成几十道专门工序，分别由专人完成。这样一来，原来意义上的“制陶工”就不复存在了，存在的只是挖泥工、运泥工、扮土工、制坯工等等制陶工匠变成了制陶工场的工人，他们必须按固定的工作节奏劳动，服从统一的劳动管理。
富士康的流水线工作机制,大家都不陌生。流水线实际上就是通过分工来提供生产效率。
现代的软件项目,很少是一个人能够开发的。往往是一个团队协作完成。这个团队就就会报包括项目经理,UI设计师,前端技术,后端技术,DBA等。这些不同工种的相互协作,最终交互一款完整的软件。
有了分工,专人专事,多人协作,就必须有一套约定俗称的项目开发流程,而这套流程其实规定了代码的组织,变量的命名等。这套流程中的代码组织继续规范和沉淀就变成了项目架构规范。
架构的艺术
架构是一门艺术,和开发语言无关。架构是整个项目的顶层设计。特别是在Devops的流行的今天,开发人员也要参与项目部署和运维的工作。站在项目架构的角度,架构不仅要考虑项目的开发,还要考虑项目的部署。
本文更多地聚焦于项目开发的架构,即中小型项目的搭建。
架构的功能:
- 方便团队分工
- 职责分离
- 可扩展
- 重用
- 方便排错
理解阿里应用分层架构
在国内Java应用方面,阿里应该是权威。在阿里《Java开发规范》中有一个推荐的分层。
-
开放 API 层： 可直接封装 Service 接口暴露成 RPC 接口； 通过 Web 封装成 http 接口； 网关控制层等。
-
终端显示层：各个端的模板渲染并执行显示的层。当前主要是 velocity 渲染，JS 渲染，JSP 渲染，移
动端展示等。 -
Web 层：主要是对访问控制进行转发，各类基本参数校验，或者不复用的业务简单处理等。
-
Service 层：相对具体的业务逻辑服务层。
-
Manager 层：通用业务处理层，它有如下特征：
1） 对第三方平台封装的层，预处理返回结果及转化异常信息，适配上层接口。
2） 对 Service 层通用能力的下沉，如缓存方案、中间件通用处理。
3） 与 DAO 层交互，对多个 DAO 的组合复用。 -
DAO 层：数据访问层，与底层 MySQL、Oracle、Hbase、OB 等进行数据交互。
-
第三方服务：包括其它部门 RPC 服务接口，基础平台，其它公司的 HTTP 接口，如淘宝开放平台、支
付宝付款服务、高德地图服务等。 -
外部数据接口：外部（应用）数据存储服务提供的接口，多见于数据迁移场景中。
分层领域模型规约：
- DO（Data Object）：此对象与数据库表结构一一对应，通过 DAO 层向上传输数据源对象。
- DTO（Data Transfer Object）：数据传输对象，Service 或 Manager 向外传输的对象。
- BO（Business Object）：业务对象，可以由 Service 层输出的封装业务逻辑的对象。
- Query：数据查询对象，各层接收上层的查询请求。注意超过 2 个参数的查询封装，禁止使用 Map 类
来传输。 - VO（View Object）：显示层对象，通常是 Web 向模板渲染引擎层传输的对象。
manager层的使用
其它层的关系,大家都很容易理解。但是manager层和service层容易搞混。这也是初学者容易迷惑的地方,笔者也是反复揣摩和多次查阅了相关资料,有了一个比较合理的理解。
笔者认为,controller调用service层,service层调用dao层(或Mapper层)。manager层出现的目的就是供其他service层使用，就是说service不能直接调用service，而是通过manager来做调用。
- manager层是对service层的公共能力的提取。
- manager层还可以下沉内部的common/helper等。
笔者所在团队,Java项目的搭建也是参照的这套标准。但是没有放之四海而皆准的标准,在实际搭建中都会根据实际业务和团队文化而因地制宜的有所改造。
这里值得注意的是manager层,我想可能很多项目是没有使用这个层的。或者直接使用的common/helper作为替代。
superblog项目架构
鉴于以上的阐述,在设计superblog的架构上就基本心中有数了。我们姑且将博客中的创作称为作品,这里就以作品创建为例来展示一下项目各层之间的调用关系。
笔者把Superblog创作定义为以下类型:
- Article(文章)
- Weekly(周刊)
- Solution(解决方案)
以上这种分层和调用关系和开发语言没有太多关系,无论是C#还是Java都是适用的,这就想三层框架，ｍｖｃ架构一样,是一种设计理念和设计模式。
架构的关系明确之后,搭建框架就是水到渠成的事情。
讲到这里,终于要轮到Springboot上场了。下面我们就以Springboot来搭建一套开发架构。
本项目包含一个父工程super-blog和 blog-base, blog-pojo,blog-dao, blog-manager, blog-service,blog-web,blog-webapi。
- blog-base,blog-pojo 为其他模块的公共模块,blog-base依赖blog-pojo;
- 七个子模块都依赖父模块,blog-dao 依赖 blog-base;
- blog-service 依赖 blog-dao，也就间接依赖 blog-base;
- blog-web和blog-webapi是并列的。都依赖 blog-service,也就间接依赖blog-base和blog-dao。
- blog-manager是blog-service中公共的业务层。
模块的概念在不同语言之间叫法不同。在
.NET Core项目中,每一层都是一个程序集,程序集之间通过引用来表达调用关系。在Springboot项目中,每一层都是一个模块,各个模块之间通过maven配置依赖关系。
比如,以下配置就表示父工程下有哪些子模块。
<!--声明子模块-->
<modules>
<module>blog-pojo</module>
<module>blog-dao</module>
<module>blog-service</module>
<module>blog-manager</module>
<module>blog-base</module>
<module>blog-webapp</module>
</modules>
而这个配置又表示了一种子模块之间的依赖关系。
<!-- 添加 blog-service 的依赖 -->
<dependency>
<groupId>com.zhike</groupId>
<artifactId>blog-service</artifactId>
<version>0.0.1-SNAPSHOT</version>
</dependency>
值得注意的是,在Springboot之间通常使用单向依赖,避免产生相互引用。双向引用在编译阶段不会报错,但是运行时就会异常。
按照惯例,也要将搭建好的项目架构展示一下:
结语
本文主要是从理论上对分层架构的进行了阐述。下一篇会讲解搭建springboot多模块的详细步骤。对于新手同学可以参考《零基础上手JavaWeb》
和《使用IDEA快速搭建一个SpringBoot项目》（详细）,先尝试搭建一个最简单的Springboot项目。
选择并聚焦到一点，把事情做到极致。
