在 DDD 和 CQRS 中，我是否应该将所需的表示逻辑直接放入每个 Read (Finder) 查询中？
In DDD and CQRS, should I just put the required presentation logic directly into each Read (Finder) query?
我正在尝试确定处理表示逻辑的最佳位置。我已经将我的读取查询 (CQRS) 与每种方法分开，为我的视图查询和生成 DTO。但是我的视图只是模板，其中散布着来自 DTO 的变量。他们没有任何逻辑。
假设我想做一些事情，比如重新格式化日期的外观，将标志变成实际的描述性词语，或者根据从数据库中查询的内容在显示的内容上添加一些条件，等等。我正在考虑将此逻辑放入每个查询中，而不用担心太干燥（我发现在某些情况下，如果你太干燥，那么你可能会使事情变得难以改变，因为你必须检查每个依赖项或者希望你的单元测试能坚持下去）。我可能会在这里和那里使用一些 "helpers" 来进行我发现我一直在做的格式化，但我认为没有必要添加一个完整的其他 "presentation layer"。因此表示逻辑将驻留在每个查询中并进入返回的 DTO，然后直接放入视图中。这将使 CQRS 的读取端保持超薄，并且有意义，因为每个视图对应于一个读取查询。但我也担心某些表示逻辑会非常特定于该领域。新上任的开发人员需要查看其他查询并重复相同的格式化技术，而不是直接从原始查询中将数据扔到那里。
这是正确的方法，还是 DDD/CQRS 中使用了另一种方法？我无法从我所做的 CQRS 研究中找到任何指导。注意：我碰巧使用的是 PHP/MySQL，但我想这个问题与语言无关。
我认为了解 CQRS 最重要的部分是它不必很复杂。事实上，对于事物的阅读方面，寻求最简单的解决方案，该解决方案将起作用且可维护。如果您只需要来自视图的 SELECT 语句来绑定到网格，为什么要制作一堆图层、DTO 和 Web 服务？这是否为业务增加了任何价值？但是，如果有合理的理由在等式中添加一个层，那么您可以这样做，通常 DTO 是在这些层之间进行通信的好方法。
您的系统可能会根据手头的用例调用不同的查询策略，因此这不一定是一种放之四海而皆准的方法。性能应该始终是您首先关注的问题之一，因此让数据尽可能接近使用的表示代码，并且只在真正需要时才增加复杂性。
有人可能会说，如果表示层直接从数据库读取，这就不是松散耦合。但是，仅仅因为两件事之间有很多层，并不会使它们松散耦合。事实上，它可能是相同的耦合量，但是现在你增加了一个维护头痛，因为每次添加一个字段你必须接触 10 个地方。
更多地关注你的命令端，做任何对阅读端来说可行的事情。
我正在尝试确定处理表示逻辑的最佳位置。我已经将我的读取查询 (CQRS) 与每种方法分开，为我的视图查询和生成 DTO。但是我的视图只是模板，其中散布着来自 DTO 的变量。他们没有任何逻辑。
假设我想做一些事情，比如重新格式化日期的外观，将标志变成实际的描述性词语，或者根据从数据库中查询的内容在显示的内容上添加一些条件，等等。我正在考虑将此逻辑放入每个查询中，而不用担心太干燥（我发现在某些情况下，如果你太干燥，那么你可能会使事情变得难以改变，因为你必须检查每个依赖项或者希望你的单元测试能坚持下去）。我可能会在这里和那里使用一些 "helpers" 来进行我发现我一直在做的格式化，但我认为没有必要添加一个完整的其他 "presentation layer"。因此表示逻辑将驻留在每个查询中并进入返回的 DTO，然后直接放入视图中。这将使 CQRS 的读取端保持超薄，并且有意义，因为每个视图对应于一个读取查询。但我也担心某些表示逻辑会非常特定于该领域。新上任的开发人员需要查看其他查询并重复相同的格式化技术，而不是直接从原始查询中将数据扔到那里。
这是正确的方法，还是 DDD/CQRS 中使用了另一种方法？我无法从我所做的 CQRS 研究中找到任何指导。注意：我碰巧使用的是 PHP/MySQL，但我想这个问题与语言无关。
我认为了解 CQRS 最重要的部分是它不必很复杂。事实上，对于事物的阅读方面，寻求最简单的解决方案，该解决方案将起作用且可维护。如果您只需要来自视图的 SELECT 语句来绑定到网格，为什么要制作一堆图层、DTO 和 Web 服务？这是否为业务增加了任何价值？但是，如果有合理的理由在等式中添加一个层，那么您可以这样做，通常 DTO 是在这些层之间进行通信的好方法。
您的系统可能会根据手头的用例调用不同的查询策略，因此这不一定是一种放之四海而皆准的方法。性能应该始终是您首先关注的问题之一，因此让数据尽可能接近使用的表示代码，并且只在真正需要时才增加复杂性。
有人可能会说，如果表示层直接从数据库读取，这就不是松散耦合。但是，仅仅因为两件事之间有很多层，并不会使它们松散耦合。事实上，它可能是相同的耦合量，但是现在你增加了一个维护头痛，因为每次添加一个字段你必须接触 10 个地方。
更多地关注你的命令端，做任何对阅读端来说可行的事情。