DDD落地篇--架构分层

架构分层

DDD中的分层

user api

用户展现层。主要负责外部服务（对外rpc接口、mq、http接口）的交互

application

command应用服务。负责安全认证、权限校验、协调领域模型和领域服务、持久化事务管理、发布领域事件

query

query应用服务。负责所有查询服务

domain

领域层。系统的核心，实现了全部的业务逻辑，表达了业务概念、业务规则。

infrastructure

基础设施层，为各层的技术能力提供支持

依赖原则

根据依赖倒置原则（高层模块不应该依赖于低层模块，两者都应该依赖于抽象，抽象不应该依赖于细节，细节应该依赖于抽象）。依赖关系如下

简单来说就是基础设施层的接口定义在其他层。基础设施层只实现这些接口。

六边形架构、整洁架构(端口与适配器)

对于每一种外界类型，都有一个适配器与之对应。外界接口通过应用层api与内部进行交互。

对于右侧的端口与适配器，我们可以把资源库看成持久化的适配器。

架构中，我们平等的看待Web、RPC、DB、MQ等外部服务，基础实施依赖圆圈内部的抽象。

当一个命令Command请求过来时，会通过应用层的CommandService去协调领域层工作，而一个查询Query请求过来时，则直接通过基础实施的实现与数据库或者外部服务交互。再次强调，我们所有的抽象都定义在圆圈内部，实现都在基础设施。

命令和查询职责分离--CQRS

• 一个对象的一个方法修改了对象的状态，该方法便是一个命令(Command)，它不应该返回数据，声明为void。
• 一个对象的一个方法如果返回了数据，该方法便是一个查询(Query)，不应该通过直接或者间接的手段修改对象状态。
• 聚合只有Command方法，没有Query方法。
• 资源库只有add/save/fromId方法。
• 领域模型一分为二，命令模型(写模型)和查询模型(读模型)。
• 客户端和查询处理器
  
  客户端：web浏览器、桌面应用等
  
  查询处理器：一个只知道如何向数据库执行基本查询的简单组件，查询处理器不复杂，可以返回DTO或其它序列化的结果集，根据系统状态自定
• 查询模型：一种非规范化的数据模型，并不反映领域行为，只用于数据显示
• 客户端和命令处理器
  
  聚合就是命令模型
  
  命令模型拥有设计良好的契约和行为，将命令匹配到相应的契约是很直接的事情
• 事件订阅器更新查询模型
• 处理具有最终一致性的查询模型

分包

module依赖

调用关系