DDD：異なるロジックを持つDTOの使用

Question

現在DDDプロジェクトに取り組んでおり、最近はDTOの使用に関する問題に直面しています。

私は（コードはPHPであるが、任意の言語でもよい）自分のドメインで次のDTOを持っている：

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になります。 ロケールが翻訳されていない場合、DTOの$textの値がnullになることを意味する、Domain-to-UI側で同じ種類のロジックを実装しました。

私のチームの開発者はフォールバックロジックを追加しました。たとえば、FRロケールが存在しない場合、ドメインはデフォルトロケール（ENなど）を返します。 UI・ツー・ドメイン「の論理が」ドメイン・ツー・UI「ロジック」によって破壊されるように私は、これで恥ずかしいた

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

：返されたドメインへのUIオブジェクトは、次のようになります。したがって、開発者の視点から見ると、このDTOを読むときには注意が必要です。フォールバックされたかどうかはわかりません。言い換えれば、私たちは本当にこのDTOを「信用する」ことができません。

一方、ドメインからの要求後にUIがオブジェクトの翻訳を気にしないため、この代替ロジックはUIレイヤーで便利です。オブジェクトには常に正しいテキストが含まれます。

さらに、これらの翻訳を管理する必要があるため（管理バックエンドなど）、DTOに「実」値（フォールバックなし）を要求するためのエンドポイントと、フォールバック値を要求するためのものです。

あなたはどう思いますか？どちらの方法がベストプラクティスですか？または、より良い代替方法がありますか？

乾杯まず

Answer 1

DTOは本当にただUIツードメインのためにする必要がありますので、あなたのドメインを照会してはいけません。

状況のクエリ側では、データを表すための単純な構造が返されている可能性がありますが、意図は異なります。このロケールデータはドメインによって提供されるわけではないため、直接問い合わせを行うためのローカリゼーションファイルを作成し、フロントエンド（SPAの場合など）でフォールバックを実行するか、作成されたプライマリローカリゼーションファイルにはフォールバックが既に含まれています。

サーバー上でフォールバックを実行することを決定した場合でも、フォールバックテキストを指定するか、指定されたテキストがフォールバック値だった場合は、そう：

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

または、

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

私は通常私のSPAソリューションで行っていることはi18next.jsとそれを使用していたが、内部的に、フォールバック・ロカので、フォールバックの世話をしますleが提供されます。要求されたリソースが見つからない場合、フォールバックが取得されます。それ以外の場合は要求されたキーが表示されます。

とにかく、いくつかの考え:)