我正在努力决定处理表示逻辑的最佳位置。我已经将我的Read查询(CQRS)分离出来，每个方法都为我的View查询并生成一个DTO。但我的视图只是一个模板，其中散布着来自DTO的变量。他们没有任何逻辑。
假设我想做一些事情，比如重新格式化日期的外观，将标志转换为实际的描述性单词，或者根据从数据库中查询的内容添加一些显示内容的条件，等等，不必担心过于枯燥(我发现，在某些情况下，如果你枯燥得太多，那么你可能会让事情很难改变，因为你必须检查每个依赖项，或者希望你的单元测试能坚持下去)。我可能会在这里和那里使用一些"助手"来进行我一直在做的格式化，但我认为没有必要添加其他的"表示层"。因此，表示逻辑将驻留在每个查询中，并进入返回的DTO，直接放入视图中。这将使CQRS的读取端保持超薄，并且每个视图都对应于一个读取查询，这是有意义的。但我也担心，这种表示逻辑中的一些会非常特定于该领域。新的开发人员需要查看其他查询并重复相同的格式化技术，而不是直接从原始查询中抛出数据。
这是一种合理的方法，还是DDD/CQRS中使用了另一种方法？我很难从我所做的CQRS研究中找到任何指导。注意：我碰巧使用的是PHP/MMySQL，但我认为这个问题与语言无关。
我认为了解CQRS最重要的部分是它不必复杂。事实上，从阅读的角度来看，选择最简单的解决方案是可行的和可维护的。如果您只需要视图中的SELECT语句来绑定到网格，那么为什么要创建一堆层、DTO和web服务呢？这会为业务增加价值吗？但是，如果有正当理由在等式中添加一个层，那么您可以这样做，通常DTO是在这些层之间进行通信的好方法。
您的系统可能会根据手头的用例调用不同的查询策略，所以这不一定是一种一刀切的方法。性能应该始终是您首先关心的问题之一，因此尽可能使数据接近消耗性的演示代码，并且只在真正需要时增加复杂性。
有些人可能会说，如果表示层直接从数据库中读取，那么这并不是松散耦合的。然而，仅仅因为两个事物之间有很多层，并不能使它们松散耦合。事实上，这可能是相同数量的耦合，但现在您增加了一个维护难题，因为每次添加字段时都必须触摸10个位置。
更多地关注你的指挥端，做任何对阅读端来说实用的事情。