前言
关于架构的理解,一千个人心中有一千个哈姆莱特。这和项目经验和团队文化有很大关系。
我想很多人其实对编程是有误解的。在中国古代提倡六艺,后面又提倡琴棋书画,这些都是才艺或者技艺。编程也是一门技艺,并没有大家想象的那么神秘。当我们通过书本学到一门编程语言的时候,往往只是学到了一些技巧,一些技术,但是要真正的成为行家,大拿,那就需要艺术了。在编程中,架构就是一门艺术。
流水线
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都是适用的,这就想三层框架,mvc架构一样,是一种设计理念和设计模式。
架构的关系明确之后,搭建框架就是水到渠成的事情。
讲到这里,终于要轮到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配置依赖关系。
比如,以下配置就表示父工程下有哪些子模块。
blog-pojo
blog-dao
blog-service
blog-manager
blog-base
blog-webapp
而这个配置又表示了一种子模块之间的依赖关系。
com.zhike
blog-service
0.0.1-SNAPSHOT
值得注意的是,在Springboot之间通常使用单向依赖,避免产生相互引用。双向引用在编译阶段不会报错,但是运行时就会异常。
按照惯例,也要将搭建好的项目架构展示一下:
结语
本文主要是从理论上对分层架构的进行了阐述。下一篇会讲解搭建springboot多模块的详细步骤。对于新手同学可以参考《零基础上手JavaWeb》 和《使用IDEA快速搭建一个SpringBoot项目》(详细),先尝试搭建一个最简单的Springboot项目。
选择并聚焦到一点,把事情做到极致。
参考:
零基础上手JavaWeb
使用IDEA快速搭建一个SpringBoot项目(详细)