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
