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).返回的Domain-to-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屋！