java 项目结构
最近难得赋闲,阅读公司内部和开源的比较优秀的项目,对于其中的package命名感触颇深,遂成此文,即为总结,也为备忘;
两种常见目录结构
标准规范的命名,对于阅读和沟通都能起到很正面的促进作用。目前比较常见的目录接口分为两类:一类MVC模式的目录接口(简单项目推荐),另一类是DDD领域设计模式(大型项目推荐);
MVC模式
概述
MVC, 模型(Model)、视图(View)和控制器(Controller); 传统的三层架构,面向过程的javaWeb分层模式,主要分为如下以下三个层次:
1. 数据访问层; 即包含数据库在内的所有数据源的操作部分
2. 业务逻辑层; 对业务数据进行逻辑处理部分
3. 表现层; 与用户交互的部分类似
常见结构
- controller : 主要是对外的接口
- service : 核心业务逻辑
- dao/mapper : 数据库访问层
- entity: 实体类,字段和数据库保持一致
- vo: 前端专用类型,避免暴露数据库结构
- common: 基础工具包和常量package
DDD领域设计模式
- domain/entity: 领域实体类,和数据库字段保持一致
- domain/value: 领域值对象,持有自己的业务属性和行为
- domain/event: 领域事件,领域中产生的一些消息事件,异步提升性能和解掉耦合依赖
- domain/factory: 领域对象工厂,复杂的领域实体类/值对象工厂类
- domain/repository: 持久化操作类
- domain/service: 领域核心逻辑
- Infrastructure: 基础设施,Infrastructure负责给三层架构提供支持,平台和框架相关的实现层
- common: 基础工具
- controller: 对外接口
关键词缩写
- biz 业务逻辑,核心的业务逻辑
- dao 数据库操作,仅只是负责数据库操作
- vo 视图对象,前端交互专用
- dto 数据传输对象
- domain: 领域模型,几乎包括了所有的业务逻辑
- PO: Persistant Object,持久化对象
- DO:Domain Object,领域对象
- VO: View Object,视图对象。Controller在返回DTO给视图时,可能还需要包括状态信息—例如操作成功/失败的状态吗、提示文本等—这时就需要在DTO外面再包一层,即View Object
个人实践
- 以x项目为例,分为两个包,x-start提供接口和和对外交互,x-service核心逻辑; 如果项目十分复杂,可以在x-servvice分拆多个独立的领域包
x-service
├── src
│ ├── main
│ │ ├── java
│ │ │ └── com
│ │ │ └── tech
│ │ │ └── x
│ │ │ ├── common
│ │ │ ├── config
│ │ │ ├── domain
│ │ │ │ ├── event
│ │ │ │ ├── factory
│ │ │ │ ├── model
│ │ │ │ ├── repository
│ │ │ │ └── service
│ │ │ └── infrastructure
│ │ │ ├── entity
│ │ │ ├── exception
│ │ │ ├── repository
│ │ │ └── util
│ │ └── resources
│ └── test
│ └── java
x-start
├── src
│ ├── main
│ │ ├── java
│ │ │ └── com
│ │ │ └── tech
│ │ │ └── x
│ │ │ ├── controller
│ │ │ ├── dto
│ │ │ └── everyday
│ │ │ ├── queue
│ │ │ │ └── delayqueue
│ │ │ ├── reflect
│ │ │ ├── sync
│ │ │ └── vertx
│ │ │ ├── model
│ │ │ └── rest
│ │ └── resources
│ │ ├── static
│ │ │ ├── assets
│ │ │ ├── css
│ │ │ └── js
│ │ └── templates
参考文档
- 领域驱动设计实践 https://www.cnblogs.com/daoqidelv/p/7648392.html
- 项目架构之传统三层架构和领域模型三层架构:https://my.oschina.net/mzdbxqh/blog/865046