架构分层
DDD中的分层
user api
用户展现层。主要负责外部服务(对外rpc接口、mq、http接口)的交互
application
command应用服务。负责安全认证、权限校验、协调领域模型和领域服务、持久化事务管理、发布领域事件
query
query应用服务。负责所有查询服务
domain
领域层。系统的核心,实现了全部的业务逻辑,表达了业务概念、业务规则。
infrastructure
基础设施层,为各层的技术能力提供支持
依赖原则
根据依赖倒置原则(高层模块不应该依赖于低层模块,两者都应该依赖于抽象,抽象不应该依赖于细节,细节应该依赖于抽象)。依赖关系如下
简单来说就是基础设施层的接口定义在其他层。基础设施层只实现这些接口。
六边形架构、整洁架构(端口与适配器)
对于每一种外界类型,都有一个适配器与之对应。外界接口通过应用层api与内部进行交互。<br/>
对于右侧的端口与适配器,我们可以把资源库看成持久化的适配器。
架构中,我们平等的看待Web、RPC、DB、MQ等外部服务,基础实施依赖圆圈内部的抽象。
当一个命令Command请求过来时,会通过应用层的CommandService去协调领域层工作,而一个查询Query请求过来时,则直接通过基础实施的实现与数据库或者外部服务交互。再次强调,我们所有的抽象都定义在圆圈内部,实现都在基础设施。
命令和查询职责分离--CQRS
- 一个对象的一个方法修改了对象的状态,该方法便是一个命令(Command),它不应该返回数据,声明为void。
- 一个对象的一个方法如果返回了数据,该方法便是一个查询(Query),不应该通过直接或者间接的手段修改对象状态。
- 聚合只有Command方法,没有Query方法。
- 资源库只有add/save/fromId方法。
- 领域模型一分为二,命令模型(写模型)和查询模型(读模型)。
- 客户端和查询处理器
客户端:web浏览器、桌面应用等
查询处理器:一个只知道如何向数据库执行基本查询的简单组件,查询处理器不复杂,可以返回DTO或其它序列化的结果集,根据系统状态自定 - 查询模型:一种非规范化的数据模型,并不反映领域行为,只用于数据显示
- 客户端和命令处理器
聚合就是命令模型
命令模型拥有设计良好的契约和行为,将命令匹配到相应的契约是很直接的事情 - 事件订阅器更新查询模型
- 处理具有最终一致性的查询模型
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。