前言

以前对这块并没有去具体了解，就是简单的了解了一些小demo的开发流程。这次对这块写个记录。

后端

分享一篇微信上的文章：《优秀的项目代码是怎样分层的》，这是来自B站一个Up主codesheep的文章。
还有一篇文章：《Java命名规范》https://mp.weixin.qq.com/s/fY9crroOviqmstTZZIM5Ew
接下里其实见得最多的就是阿里的这张图以及阿里的解释

图片解释：

• 开放 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 向模板渲染引擎层传输的对象。

尽量对整个Maven工程结构进行分层拆分，增加工程的可扩展性，实现高内聚低耦合的开发要求。
例子：图中将工程拆分为一个父工程和三个子工程：
•CancerCenter：父工程，只有POM的约束，无具体业务代码。
•CancerCenter_Common：通用工程，最下层依赖，包含utils，model，exception等整个项目的公共模块，提供整个项目的基础支撑。
•CancerCenter_Service：业务工程，向下依赖于Common，向上被Web依赖，包含service和mapper，是整个项目的核心业务。
•CancerCenter_Web：Web工程，向下依赖于Service，对外提供接口，包含接口、配置等Web项目独有的模块。

前端

├── build/                      # webpack 配置文件；
├── config/                     # 与项目构建相关的常用的配置选项；
│   ├── index.js                # 主配置文件
│   ├── dev.env.js              # 开发环境变量
│   ├── prod.env.js             # 生产环境变量
├── src/
│   ├── main.js                 # webpack 的入口文件，公共js文件；
│   ├── router.js               # webpack 的入口文件；
│   ├── assets/               	#资源目录；
│   ├── components/               #组件目录；
│   ├── store/               	#vuex目录；
│   ├── ....			#页面级vue组件；
├── static/                       # 纯静态资源，该目录下的文件不会被webpack处理，
├── .babelrc                      # babel 的配置文件
├── .editorconfig                # 编辑器的配置文件；可配置如缩进、空格、制表类似的参数；
├── .gitignore                   # git的忽略配置文件
├── index.html                   # HTML模板
├── package.json                # npm包配置文件，里面定义了项目的npm脚本，依赖包等信息
├── pub.js                       # 发版脚本文件
└── README.md

1.资源路径编译规则
默认情况下，vue-loader 使用 css-loader 和 Vue 模版编译器自动处理样式和模版文件。在编译过程中，所有的资源路径例如 、background: url(…) 和 @import 会作为模块依赖。
路径的编译规则如下：
如果路径是绝对路径，会原样保留；
如果路径以 . 开头，将会被看作相对的模块依赖，并按照你的本地文件系统上的目录结构进行解析；
如果路径以 @ 开头，也会被看作模块依赖。如果你的 webpack 配置中给 @ 配置了 alias，这就很有用了。所有 vue-cli 创建的项目都默认配置了将 @ 指向 /src；

2.build目录和config目录
build 目录下存放的是 webpack 的配置文件；
config 目录下存放的是与项目构建相关的常用的配置选项、变量；
通常情况下，除非要配置 webpack 的 loader 或者 插件，否则，你应该优先尝试更改 config 目录下的文件；

​

3.src目录
根据项目结构的核心思想，src的目录结构将以业务功能划分。
注意事项：
I . 项目的业务代码应该从 src/app/ 目录开始；
II . src/common/ 的子目录中，在深度上的层级结构应该是尽量扁平的，不应该有很深的层级结构；如果 src/common/ 中的目录树 与 src/app/ 中的目录树在深度上有十分相似的层级结构，则就表示你应该重新考虑 src/common/ 中的资源是否是真的需要被共享的资源，被共享的资源的目录层级结构应该是尽可能扁平的；对于不必共享的资源，应该放在 src/app/ 下相应的目录结构中；
III . src文件或文件夹的组成分为3种。直接在src目录下的vue文件是工程内直接于业务相关页面文件；components文件夹下是组件文件；其他文件夹是一些活动和主业务耦合性不大的文件。

4.static目录
static目录可以添加任何资源，如：图片、代码 等等。不过工程内图片大多存放七牛，static/project.js存放公共函数

微信文章：https://mp.weixin.qq.com/s/mNWc2tJWZlxJkKQh-kNpVg；可以参考一下，做个简单的前端认识。
下图来自于该篇文章。

最后

平时没事可以看看《阿里开发手册》，有助于对Java项目的开发流程的认识以及对规范的认识，可以有个良好的开发习惯。