DDD: DTO usage with different logic

问题

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

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(...);
}

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,
]

Now the question:

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.

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',
]

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.

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.

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?

Cheers

回答1:

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

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.

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'
}

or,

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

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 :)

来源：https://stackoverflow.com/questions/43951804/ddd-dto-usage-with-different-logic

标签

architecture

domain-driven-design

dto