1.DDD带来的问题

为了遵守"代码和模型一致的原因"，引入的问题：

1）程序编写比较麻烦，原来一句 SQL 就可以解决的问题，现在要分几步实现。

2）这样的程序可能带来性能问题。

核心问题是，查询功能是否必须经过领域模型呢？

2.分析问题

为什么之前的逻辑要经过领域模型。其中一个主要原因是，如果绕过领域模型，领域逻辑和数据就可能分散在程序各个地方，无法保证数据的完整和一致性，程序也将很难理解和维护。对于增、删、改这样的逻辑，这样的原因确实说得通。 但是，查询的逻辑并不会改变数据，所以并不会造成数据的不完整和不一致。

3.解决问题

事实上，前人已经意识到了查询和其他功能的不同之处，主张采用不同的方式来处理查询逻辑，并提出了所谓 CQRS 架构。

最早提出这个说法的是 Greg Young。他把增、删、改功能称为 Command（命令），把查询称为 Query，这两种功能的职责不同，应该采用不同的方式来处理，因此叫做“命令查询职责分离”（Command Query Responsibility Segregation ），简称 CQRS。

简单理解，一共是两条规则。

第一，命令要走领域模型。

第二，查询不走领域模型，直接用 SQL 和 DTO。

此文章为3月Day3学习笔记，内容来源于极客时间《手把手教你落地 DDD》