项目结构

src

| -- api 应用接口层
    | -- controller
    | -- rpc

| -- application 应用服务层
    | -- dto 传输转换
    | -- service 应用服务

| -- domain 领域模型层
    | -- model 领域数据模型
    | -- repository 领域数据仓库 / 数据抽象层

| -- infrastructure 基础设施层
    | -- entity 数据库表模型
    | -- mapper / dao 数据库表操作层
    | -- mq 消息队列
    | -- event 本地消息驱动
    | -- config 基础设施配置

| -- project 工程通用设施
    | -- annotation 自定义注解
    | -- aop 自定义切面
    | -- com 自定义组件
    | -- common 通用数据结构
    | -- config 工程配置
    | -- exception 自定义异常
    | -- handler 自定义handler
    | -- interceptor 自定义拦截器
    | -- util 常用工具

项目架构图

项目架构说明

用户接口层：

负责入口方向的外部依赖。对外暴露接入端点，使得内部的业务逻辑能够以服务的方式供外部系统消费。根据外部系统的特点（如接口协议、数据格式）设计出对应的接口。比如便于Web界面和APP消费的RESTFul接口形式、面向第三方服务的开放接口形式、消息队列监听形式、定时任务形式等等。往往是一种消费形式就对应一个接口。接口层要负责把不同外部系统的接口协议和参数转成下层的应用服务熟悉的协议和参数。另有几个注意事项：

• 不要有任何业务逻辑的内容。
• 不要直接依赖基础设施层，而是通过业务逻辑形成对基础设施层的间接依赖。

应用服务层：

本层负责把业务服务以合适的粒度暴露给外部消费。 它和用户接口层的接口设计粒度不一样，一个应用服务应该对应一种业务能力，可以等同于一个用户用例。比如健康码查询是一种业务能力，它只要设计成一个应用服务，但入口的接口可能设计为多个，用来接入多种触发查询的系统。因此本层主要干两件事：

• 通过编排各种领域模型的能力组装出一个用户用例。就拿创建订单这个用例来说，往往涉及了订单聚合的创建（包括了订单业务逻辑处理）、订单资源库的保存、领域事件的发布。
• 提供业务能力的服务过程中必要的一些横向事情。比如启动数据库事务，打印日志，捕捉和处理异常。

领域模型层：

负责通过合适的领域模型来承载业务逻辑，DDD建模结果应该在本层得到体现。不应出现任何跟具体技术相关的词汇，比如资源相关的操作只有Repository，没有JDBC、MyBatis、Redis等具体的技术实现。另外还需要针对每种业务逻辑必要的底层依赖设计出合适的适配接口。

基础设施层：

本层主要负责实现各种适配接口，典型的有：

• 对资源存储的访问比如数据库、缓存系统
• 对组织内部其他系统的适配逻辑，一般通过内部rpc协议访问
• 对组织外部第三方厂商系统的适配逻辑
• 对基础框架中间件的适配逻辑，比如消息队列、配置中心、文件系统、监控系统等等。