Domain driven design 在DDD和CQRS中，我是否应该将所需的表示逻辑直接放入每个读取（查找器）查询中？

我正在努力决定处理表示逻辑的最佳位置。我已经将我的读取查询（CQR）与每个方法分开，为我的视图查询并生成DTO。但我的视图只是带有分散变量的模板，这些变量将来自DTO。他们没有任何逻辑

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

---

这是合理的方法，还是在DDD/CQRS中使用了另一种方法？我很难从我所做的CQRS研究中找到任何指导。注意：我碰巧使用的是PHP/MySQL，但我认为这个问题与语言无关。

我认为理解CQRS最重要的部分是它不必复杂。事实上，从阅读的角度来看，应该选择最简单的解决方案，它可以工作并且可以维护。如果您只需要从视图中选择一条语句来绑定到网格，那么为什么要创建一堆层、DTO和web服务呢？这会给企业增加价值吗？但是，如果有正当理由在等式中添加一个层，那么您可以这样做，通常DTO是在这些层之间进行通信的好方法

您的系统可能会根据手头的用例调用不同的查询策略，因此这不一定是一种一刀切的方法。性能应该始终是您最关心的问题之一，因此让数据尽可能接近消耗性的表示代码，并且只在真正需要时增加复杂性

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

---

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

我在这里又提出了一个关于CQR的问题