Springboot项⽬架构设计
导航
前⾔
流⽔线
架构的艺术
项⽬架构
理解阿⾥应⽤分层架构
superblog项⽬架构
结语
参考
本节是的第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>
spring系列框架有哪些
<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多模块的详细步骤。对于新⼿同学可以参考 和，先尝试搭建⼀个最简单的Springboot项⽬。
选择并聚焦到⼀点，把事情做到极致。
参考:
该系列往期⽂章
(思维篇)⼈⼈都是产品经理
1.需求⽂档
1.1
1.2
1.3
2 原型设计
2.1
2.2

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。