domain-driven-design - 在 DDD 和 CQRS 中，我是否应该将所需的表示逻辑直接放入每个 Read (Finder) 查询中？

Question

我正在尝试确定处理表示逻辑的最佳位置。我已将读取查询 (CQRS) 与每个查询方法分开，并为我的 View 生成 DTO。但我的 View 只是带有分散的变量的模板，这些变量将来自 DTO。他们没有任何逻辑。

假设我想做一些事情，例如重新格式化日期的外观，将标志转换为实际的描述性单词，或者根据从数据库查询的内容在显示内容上添加一些条件，等等。我正在考虑将这个逻辑放入每个查询中，并且不用担心太干燥(我发现在某些情况下，如果您干燥太多，那么您可能会使事情很难改变，因为您必须检查每个依赖项或者希望你的单元测试能够通过)。我可能会在这里或那里使用一些“助手”来进行我发现我一直在做的格式化，但我认为没有必要添加整个其他“表示层”。因此，表示逻辑将驻留在每个查询中并进入返回的 DTO，然后直接放入 View 中。这将使 CQRS 的读取端保持超薄，并且有意义，因为每个 View 对应一个读取查询。但我也担心一些表示逻辑对于该领域来说是非常特定的。新加入的开发人员需要查看其他查询并重复相同的格式化技术，而不是直接从原始查询中抛出数据。

这是正确的方法，还是 DDD/CQRS 中使用了其他方法？我无法从我所做的 CQRS 研究中找到任何指导。注意:我碰巧使用的是 PHP/MySQL，但我想这个问题与语言无关。

Answer 1

我认为理解 CQRS 最重要的部分是它不必太复杂。事实上，对于事物的阅读方面，应选择最简单、可行且可维护的解决方案。如果您只需要从 View 中使用 SELECT 语句来绑定(bind)到网格，那么为什么要创建一堆层、DTO 和 Web 服务呢？这能为业务增加任何值(value)吗？但是，如果有正当理由在等式中添加一个层，那么您可以这样做，并且通常 DTO 是在这些层之间进行通信的好方法。

您的系统可能会根据当前的用例调用不同的查询策略，因此这不必是一种通用的方法。性能应该始终是您首先关心的问题之一，因此使数据尽可能接近使用的演示代码，并且仅在真正需要时才增加复杂性。

有些人可能会说，如果表示层直接从数据库读取，那么这不是松散耦合的。然而，仅仅因为两个事物之间有很多层，并不会使它们松散耦合。事实上，可能是相同程度的耦合，但现在您增加了维护麻烦，因为每次添加字段都必须触及 10 个位置。

更多地关注你的命令端，并做任何对阅读端来说可行的事情。