「这是我参与2022首次更文挑战的第15天，活动详情查看：2022首次更文挑战」   昨天学到了DDD的清洁架构，今天继续DDD剩下的架构模式。

DDD之六边形架构

六边形架构如其名，由外而内看进去就是一个六边形，如下图： 和清洁架构相似，六边形架构的请求都是经由api转换之后交由内部去处理，参数也只能传递业务参数，不应和第三方相关的api参数产生耦合，做到领域层可以不依赖任何基础设施的实现，不关心底层逻辑。由图我们可以看到，六边形架构依然遵循了单向依赖原则，请求由表现层一直往内，有利于我们对代码的梳理，不会出现一团乱码的引用。领域层对基础设施层通过SPI进行解耦，彻底脱离对基础设施的依赖。六边形架构的包结构如下：

api 对外接受请求
adapter 对请求进行转换接口，有对api请求的转换能力
domain 领域对象，有业务执行能力
spi 基础设施抽象接口，领域对象所依赖的基础设施能力
infrastructure 对SPI基础设施实现，提供底层支撑能力

总的来说，六边形架构和清洁架构及其相似，都是要求领域对象有独立执行的能力，不能直接依赖基础设施的实现。

CQRS架构

我们知道，DDD中，对业务的操作称之为一个命令，无论是查询还是新增，都是由命令来表示的。这种方式有个缺点，当我们项目中需要做读写分离时，它就不是很灵活，CQRS架构就是用来解决这种事情的。CQRS中将功能分为读取数据和写入命令。这样，我们写入数据和读取数据就可以分开实现，对于复杂的报表请求，交由读取功能的实现，而命令只做简单的增删改操作。对于复杂的查询系统，单独的查询能力可能会给系统带来质的提升。