DDD：具有不同逻辑的 DTO 用法答案

【问题标题】：DDD: DTO usage with different logicDDD：具有不同逻辑的 DTO 用法
【发布时间】：2017-10-12 14:30:08
【问题描述】：

我目前正在从事一个 DDD 项目，最近遇到了有关使用 DTO 的问题。

我的域中有以下 DTO（代码是 php，但可以是任何语言）：

class TranslationDto {
    private $locale;
    private $text;

    public function getLocale(...);
    public function getText(...);
}

目标是 UI 将为域提供具有区域设置及其相应文本的 DTO。例如，如果区域设置“FR”未翻译，则 DTO 将如下所示：

// UI => domain, for example when willing to persist the data (write)
TranslationDto [
    'locale' => 'FR',
    'text' => null,
]

现在的问题：

在 UI 到域的流程中，如果未翻译语言环境，则 DTO 的 $text 值将是 null。我在 Domain-to-UI 端实现了相同的逻辑，这意味着如果没有翻译语言环境，那么 DTO 的 $text 值将是 null。

但是，我团队中的一位开发人员添加了回退逻辑，例如，如果 FR 区域设置不存在，则域将返回默认区域设置（例如 EN）。返回的 Domain-to-UI 对象将如下所示：

TranslationDto [
    'locale' => 'FR',
    'text' => 'The fallback text, in english',
]

对此我感到很尴尬，因为 UI 到域的“逻辑”会被域到 UI 的“逻辑”破坏，因此从开发人员的角度来看，我们需要小心这个 DTO阅读它时，如果它是否被回退，我们现在不会。换句话说：我们不能真正“信任”这个 DTO。

另一方面，这种回退逻辑在 UI 层更方便，因为 UI 不会关心在从域请求对象后翻译对象：它始终包含正确的文本。

此外，由于我们需要管理这些翻译（例如在管理后端），我们现在将有 2 个端点而不是 1 个：一个用于请求具有“真实”值的 DTO（没有回退），一个用于用他们的后备值请求他们。

你们对此有何看法，哪种方法是最佳实践？或者有没有更好的替代方法？

干杯

【问题讨论】：

【解决方案1】：

首先，您不应该查询您的域，因此 DTO 应该只用于 UI-to-Domain。

查询方面很可能会返回一些简单的结构来表示数据，但意图不同。由于域不会提供此语言环境数据，因此您最终可能会生成用于直接查询的本地化文件，然后在前端执行回退（例如在 SPA 案例中），或者您生成的主要本地化文件已经包含回退.

即使您要返回一些结构，甚至是 DTO，并且您决定在服务器上执行回退，提供回退文本或指示所提供的文本是回退值可能很有用，所以：

{
   locale: 'fr',
   text: undefined,
   fallback: 'Anglais'
}

或者，

{
   locale: 'fr',
   text: 'Anglais',
   fallback: true
}

我在我的 SPA 解决方案中所做的通常是使用 i18next.js 并且 it 在内部负责处理后备，因为提供了后备语言环境。如果请求的资源丢失，则检索回退；否则显示请求的密钥。

无论如何，只是一些想法:)

【讨论】：