DDD架构简单介绍

DDD架构

1. DDD分层架构

	DDD(领域驱动设计)由Eric Evans最先提出，目的是对软件所涉及到的领域进行建模，以应对系统规模过大时引起的软件复杂性的问题。从领域知识中提取和划分一个一个的子领域（核心子域，通用子域，支撑子域）并在子领域上建立模型，再重复以上步骤，这样周而复始，构建出一套符合当前领域的模型。
	依靠领域驱动设计的思想，通过事件风暴建立领域模型，合理划分领域逻辑和物理边界，建立领域对象及服务矩阵和服务架构图，定义符合DDD分层架构思想的代码结构模型，保证业务模型与代码模型的一致性。通过上述思想，方法和过程，指导团队按照DDD设计思想完成微服务设计和开发。

• 拒绝泥球小单体，拒绝污染功能与服务，拒绝一加功能排期一个月
• 架构出高可用极易符合互联网高速迭代的应用服务
• 物料化，组装化，可编排的服务，提高人效

2. 四层模型

应用层(application)

• 应用服务位于应用层。用来表述应用和用户行为，负责服务的组合，编排和转发，负责处理业务用例的执行顺序以及结果的拼装。

• 应用层的服务包括应用服务和领域事件相关服务。

• 应用服务可对微服务内的领域服务以及微服务外的应用服务进行组合和编排，或者对基础层如文件，缓存等数据直接操作形成应用服务，对外提供粗粒度的服务。

• 领域事件服务包括两类： 领域事件的发布和订阅。通过事件总线和消息队列实现异步数据传输，实现微服务之间的解耦
  领域层(domain)

• 领域服务位于领域层，为完成领域中跨实体或值对象的操作转换而封装的服务，领域服务以实体和值对象相同的方式参与实施过程

• 领域服务对于同一个实体的一个或多个方法进行组合和封装，或对多个不同实体的操作进行组合或编排，对外暴漏成领域服务。领域服务封装了核心的业务逻辑。实体自身的行为再实体类内部实现，向上封装成领域服务暴露

• 为隐藏领域层的业务逻辑实现，所有领域方法和服务等均通过领域服务对外暴露

• 为实现微服务内聚合之间的解耦，原则上禁止跨聚合的领域服务调用和跨聚合的数据相关互联。
  基础层(infrastructure)

• 基础服务位于基础层，为各层提供资源服务(如数据库，缓存等)，实现各层的解耦，降低外部资源变化对业务逻辑的影响。

• 基础服务主要为仓储服务，通过依赖反转的方式为各层的解耦，降低外部资源变化和业务逻辑的影响。
  接口层(interfaces)

• 接口服务位于用户接口层，用于处理用户发送的Resultful请求和解析用户输入的配置文件等，并将信息传递给应用层。

总结

DDD结构是一种充血模型结构，所有服务实现都以领域为核心，应用层定义接口，领域层实现接口，领域层定义数据仓储，基础层实现数据仓储关于持久层的操作，但同时几方又有互相的依赖。
MVC架构是一种贫血模型