一张图看懂DDD+CQRS架构

Louis XIV原创2025/2/13...大约 5 分钟

一张图看懂DDD+CQRS架构

今天我要用一张图讲清楚DDD+CQRS架构，看懂这张图，DDD就学会了。不废话，直接上图：

DDD是什么

DDD的全称是领域驱动设计 Domain Driven Design，是广泛应用于系统架构设计的一种方法论。

目前业界对DDD的态度实际上褒贬不一，有些人觉得很牛，有些人觉得一文不值。但据我观察，持否定态度的人多数是半懂不懂，只是听别人说“很复杂”，自己往往说不出个所以然来。当然也确实有一些大牛分析到，DDD应用在中小型项目中会显得有些臃肿，这我是认可的，但遗憾的是我也并未看到有人提供了更优解。

我本人并不是DDD的狂热拥趸，只是它确实给了我一种解决问题的思路，并且我认为行之有效。但若你有更好的解决方案，我也十分愿意请教。

提示

如果你对DDD一知半解，我另外有一篇文章《三句话说清DDD的思想内核》，希望能带你入门

这张图我是反反复复推敲了好几年，也参考了许多业界大佬的思路，最终形成此图。

接下来我们沿着这张图，来聊一聊DDD的分层架构，你会看到这其中的设计十分巧妙。

分层解析

基础设施层

基础设施层 infrastructure 处在架构的最外围，这一层与业务规则完全无关。

通用能力和技术框架严格来说是可以不放在这一层的，完全可以放到单独的技术框架中
入口网关负责协议转换，把外部请求转化为标准的内部接口进行调用，例如controller就是把HTTP(S)请求转为内部请求。如果技术框架做得好，这一层其实也可以没有，例如dubbo框架就是把协议转换包装在框架内部
出口网关负责把系统对外的调用进行包装，包括对数据库、缓存、消息队列、下游系统等

基础设施层就像是城堡的城墙，把城堡围与外部隔开，入口网关、出口网关就是城堡的大门

接口定义层

接口定义层 interface layer只定义接口不实现，这里用到的是facade模式，统一把系统对外的服务包装成接口

我这里借鉴了CQRS架构模式（Command Query Responsibility Segregation），把facade api和query api分开，除了可以做读写分离以外，更重要的原因是有些业务的查询特别复杂，例如电商业务，用户打开一个页面除了要查询商品，还要查优惠券、推荐、关系链等，这时候把Command和Query分开是很好的选择。

Query请求是不需要经过应用服务层的，可以直接查询数据库、缓存等。

应用层

也叫应用服务层 Application Service

职责1：实现facade api，这样系统才能提供完整服务。

提示

facade接口定义是与用例分析密切相关的，可以参考《为什么说用例设计在软件开发中很重要》

职责2：负责组装领域层的服务，这一层只做编排，不写业务逻辑

提示

不写业务逻辑的意思是：不做逻辑判断、不做数值计算、没有业务规则

职责3：负责调用出口网关，调用出口网关需通过防腐层（ACL Anti-Corruption Layer) 接口，ACL是为了避免外部系统的变更对业务代码直接产生影响（例如缓存组件升级、下游接口升级等）。注意ACL是在应用层定义，并由出口网关来实现，这里用到一个控制反转（IoC Inversion of Control)
职责4：负责事务管理。开启事务、提交事务、回滚事务等