DDD:不同逻辑的DTO用法 [英] DDD: DTO usage with different logic

问题描述

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

I am currently working on a DDD project and recently faced an issue regarding the use of DTOs.

我的域中有以下 DTO(代码是 php，但可以是任何语言):

I have the following DTO in my domain (code is in php but could be in any language):

class TranslationDto {
    private $locale;
    private $text;

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

目标是 UI 将为域提供一个带有区域设置及其相应文本的 DTO.因此，例如，如果未翻译区域设置FR"，则 DTO 将如下所示:

The goal is that the UI will give the domain a DTO with a locale and its corresponding text. So for example, if the locale "FR" is not translated, the DTO will look like the following:

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

现在的问题:

在 UI 到域的流程中，如果未翻译区域设置，则 DTO 的 $text 值将为 null.我在域到 UI 端实现了相同类型的逻辑，这意味着如果不翻译语言环境，那么 DTO 的 $text 值将是 null.

On the UI-to-domain flow, if a locale is not translated, then the DTO's $text value will be null. I implemented the same kind of logic on the Domain-to-UI side, meaning that if the locale is not translated, then the DTO's $text value will be null.

但是，我团队中的开发人员添加了回退逻辑，因此例如如果 FR 语言环境不存在，域将返回默认语言环境(例如 EN).返回的域到 UI 对象将如下所示:

However, a developer in my team added a fallback logic, so for example if the FR locale does not exist, the domain will return the default locale (for example EN). The returned Domain-to-UI object will then look like this:

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

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

I was embarassed with this, as the UI-to-domain "logic" will be broken by the domain-to-UI "logic", hence from the developer's point of view, we will need to be careful with this DTO when reading it, as we will not now if it was fallbacked or not. In other words: we can't really "trust" this DTO.

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

On the other hand, this fallback logic is more convenient on the UI layer, as the UI will not care about translating the object after requesting it from the domain: it will always contain the correct text.

此外，由于我们需要管理这些翻译(例如在管理后端)，我们现在将有 2 个端点而不是一个:一个用于请求具有真实"值的 DTO(无回退)，另一个用于请求请求他们提供后备价值.

Moreover, as we need to manage those translations (in an admin backend for example), we will now have 2 endpoints instead of one: one for requesting the DTOs with their "real" value (without fallback), and one for requesting them with their fallback value.

你们怎么看这个，哪种方法是最佳实践?或者有没有更好的替代方法?

What do you guys think of this, which method is the best practice? Or is there any better alternative method?

干杯

推荐答案

首先，你不应该查询你的域，所以 DTO 应该只是用于 UI 到域.

Firstly, you should not query your domain so the DTO should really just be for UI-to-Domain.

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

The query side of things may very well be returning some simple structure to represent the data but the intent is different. Since this locale data is not going to be provided by the domain you probably end up either producing localisation files for querying directly and then perform fallback on the front-end (say in a SPA case) or your produced primary localisation files contain a fallback already.

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

Even if you were to return some structure, or even a DTO, and you decide to perform the fallback on the server it may be useful to either provide the fallback text, or indicate that the text provided was a fallback value, so:

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

或者，

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

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

What I have typically in my SPA solutions done was to use i18next.js and it, internally, takes care of the fallback since a fallback locale is provided. If the requested resource is missing then the fallback is retrieved; else the requested key is displayed.

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

Anyway, just some thoughts :)

这篇关于DDD:不同逻辑的DTO用法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！