1.从上面2张图，可以直观的看出来，ddd可以调用的程度更大，上层可以直接调用下层的 全部层
2.直接分析，ddd每层 都 放什么东西，和mvc的 放法有什么区别，知道了ddd每层放什么，又知道了每层 可以调下面 所有层，那么写代码，建立的包放哪，怎么建包，以及 哪个包 可以 调 哪些包的内容，就知道了，就可以放心写代码了，就行了
DDD 代码架构
层次上分为四层
• api：用户接口层，向外提供服务
• app：应用层，包含应用服务，负责用例流程调度，事务控制
• domain：领域层，包含领域对象和领域服务，专注核心业务
• infra：基础设施层，提供数据持久化、防腐层实现、第三方库、消息等
api 层(可以看作 mvc的 controller，几乎可以按原来的 controller用)
• controller：提供资源服务，XxxController.java• dto：数据传输对象，XxxDTO.java，对于一些复杂页面需要多个实体组合时，可使用DTO对象来传输数据。简单来说，接受前端传来的参数的时候如果不用实体类，就用DTO接收。
app 层
• service：应用服务，XxxService.java，应用服务里进行事务控制，流程调度
• service.impl：应用服务实现，XxxServiceImpl.java简单的 service，反正就是理解成 一部分service及其实现类，可以放这里 • assembler：DTO组装器，XxxAssembler.java，复杂DTO的组装，简单的直接使用Entity即可(用不用都行)
job调度
import导入逻辑
valid校验逻辑
domain 层
• entity：实体对象，与表做映射，具备一些简单的自治的业务方法
• vo：值对象，XxxVO.java，领域内用到的数据封装，对于一些没有实体对象的数据对象但又在领域中用到，使用值对象封装，简单来说，return给前端页面的 用 VO，从前端接受的用DTO
• service：领域服务，命名一般按提供的业务功能命名，通常用于封装一个领域内的复杂业务逻辑，简单的业务逻辑在app 层完成即可，不需要领域层。另一部分 复杂的 service及其实现类，到这里service就全部 完整了
• repository：资源库接口，XxxRepository.java，提供数据资源的操作方法，如数据库增删改查、Redis增删改查等，查询操作建议写到 repository 内。直接操作 各种数据源的 接口
infra 层
• mapper：Mapper接口，XxxMapper.java
• repository.impl：资源库实现，XxxRepositoryImpl.java，业务一定不要侵入到这里上面，repository接口的实现类，注意这不一定是操作 数据库的，可能是redis，mq等等数据源 的直接操作 • constant：常量
• util：工具
• intrs: 接口平台
• feign: feign调用
上面几个地方要注意的（和mvc不同的）
1.app层，只有一部分service和impl，实话大多简单（看你怎么定义，你所有service都放这里都可以）
2.domain层，有另一部分 复杂service（看你怎么定义，你不放任何service在这都可以）
3.domain层 还放了，repository接口，但是只是在这里定义接口，真正的实现类还是在 infra层
4.infra层，repository的实现类， mapper,工具类，,intrs,feign，简单理解为
不涉及业务的，都可以放在这里
5.app和domain的 service可以直接解决问题，也可以调用 infra的 repository实现类
或者 mapper，调用他们 来解决数据的 问题repository和service的区别
简单来说 service里面处理所有业务，都是只要涉及与数据源有关的业务逻辑，不要写在这里面，写在 repository,例如只要涉及 xxx查询/新增/删除/更新等
而 repository的所有业务逻辑都是围绕 crud的简单来说
service里面就是在大量业务逻辑中，有少量的 涉及数据的 repository的，service存在的目的是处理业务逻辑中 ，穿插 对数据源的操作，repository可直接操作，也可间接操作数据源
而repository存在的目的就是对数据操作，所以 repository主要目的就是 调用各种 mapper获得数据(也可能是 redis),然后对数据 进行 组合过滤拼接，以及简单的业务判断，逻辑判断后，返回整体数据
