领域驱动下cloud项目中单个服务的示例

 Domain Driven Design - 领域驱动设计【重点在于设计】

每个人和每个项目对于DDD的理解和实施都是有不同的看法，这里所指出的架构方案也只是其中的一种方式而已。

核心的想法就是让代码高内聚，低耦合，让项目的重点放在领域逻辑，而并不是在表现输出上。

这里的四层架构也是DDD所倡导的，核心理念这里就不多说了...外面说理念的文章太多了..这里就给大家看下在我搭建的微服务架构下DDD的践行方式

 

Demo-application  定义软件要完成的任务，这一层很轻，没有业务的标识，只是为领域层起到协调任务【服务】的作用
|- com.ddd.demo 
|- service 定义项目中可提供的服务
XXXservice 
  |- aop 定义切面要处理的业务：处理日志记录等
Demo-domain  领域层，这一层是业务的核心，虽然细节都是由基础设施层完成，但是这一层数聚合基础设施完成业务的表达层
|- com.ddd.demo
  |- XXX  包为application中定义的服务名称，具体实现类在此包下实现
|- impl 具体服务的实习类，实现 XXXservice的接口
|- repo 定义需要从基础设施层的仓库接口
|- vo   定义服务内的服务实现类的返回值,也是基础设施层仓库实现类返回数据标准
Demo-infrastructure 基础设施层，像其他层提供表达能力，内部与数据进行交互，包括不仅限于数据库。
 |- entity  实体类，作为数据查询的映射 
 |- mapper 数据存储对象，相当于dao层
 |- repo   具体仓库的实现类，实现domain中的repo接口
 |- utils   工具包
 |- config  配置类
Demo-interfaces 表示层，用于接收系统外部的请求和其他服务的调用
 |- dto  数据传输对象，可在此做数据校验
 |- facade 表示层，这里用于做接收请求也就是控制器
 |- feign 跨服务的接口调用定义的api