4

コードが属するDDDでの検証などについて議論するのは私の意図ではなく、1つの可能なアプローチとローカリゼーションの問題に対処する方法に焦点を当てることです。シナリオを例示するドメインオブジェクト（エンティティ）の1つで、次の動作（メソッド）があります。

public void ClockIn()
{
    if (WasTerminated)
    {
        throw new InvalidOperationException("Cannot clock-in a terminated employee.");
    }

    ClockedInAt = DateTime.Now;
    :
}

ご覧のとおり、ClockInメソッドが呼び出されると、メソッドはオブジェクトの状態をチェックして、Employeeが終了していないことを確認します。従業員が終了した場合、「エンティティを無効な状態にしない」アプローチと一致する例外をスローします。

私の問題は、例外メッセージをローカライズする必要があることです。これは通常、（このアプリケーションでは）メソッドへのアクセスを必要とするクラスでMEFを使用してインポートされるアプリケーションサービス（ILocalizationService）を使用して行われます。ただし、他のDIフレームワークと同様に、依存関係は、オブジェクトがコンテナーによってインスタンス化された場合にのみ注入/インポートされます。これは通常、DDDには当てはまりません。

さらに、DDDについて私が学んだことはすべて、ドメインオブジェクトに依存関係を持たせてはならず、それらの懸念はドメインオブジェクトの外部で処理する必要があるということです。その場合、上記のようなメッセージをローカライズするにはどうすればよいですか？

非常に多くのビジネスアプリケーションがグローバリゼーション/ローカリゼーションを必要とするため、これは新しい要件ではありません。これを機能させ、それでもDDDの目標と一致させる方法についていくつかの推奨事項をいただければ幸いです。

アップデート

私は当初、ローカリゼーションがすべてデータベース駆動型であることを指摘できなかったため、ローカリゼーションサービスがあります（注入可能なILocalizationServiceインターフェイスを介して）。したがって、プロジェクトの一部としてVisual Studioが提供する静的リソースクラスを使用することは、実行可能なオプションではありません。

別の更新

おそらくそれは、アプリがRESTfulサービスアプリであると述べるために議論を進めるでしょう。したがって、クライアントは単純なWebブラウザである可能性があります。そのため、呼び出し元があらゆる種類のローカリゼーション、コードマッピングなどを実行できることを期待してコーディングすることはできません。例外が発生した場合（このアプローチでは、ドメインオブジェクトを無効な状態にしようとすることは例外です）、例外がスローされ、適切なHTTPステータスコードが例外メッセージとともに返されます。例外メッセージは、呼び出し元の文化（Accept-Language）にローカライズする必要があります。

4

4 に答える 4

2

この応答があなたにとってどれほど役立つかはわかりませんが、ローカリゼーションは実際にはフロントエンドの懸念事項です。エンドユーザーは例外メッセージに記載されているような技術的な詳細を見るべきではないため、例に従って例外メッセージをローカライズすることは一般的ではありません（また、例外のトラブルシューティングを行う人は、母国語でなくても十分なレベルの英語を持っている可能性があります） ）。

もちろん、必要に応じて、いつでも例外を処理し、フロントエンドのユーザーにローカライズされたユーザーフレンドリーなメッセージを表示できます。しかし、それをフォントエンドの懸念として維持することで、アーキテクチャを簡素化する必要があります。

于 2012-04-13T16:26:54.617 に答える
1

Clafouが言ったように、UIにメッセージを渡すために例外を使用するべきではありません。

それでもこれを行うことを主張する場合、1つのオプションは、メッセージの代わりにエラーコードをスローすることです。

throw new InvalidOperationException("ERROR_TERMINATED_EMPLOYEE_CLOCKIN");

そして、それが発生した場合は、例外を除いて必要なことをすべて実行します（ログ、ローカリゼーションの検索など）。

于 2012-04-13T18:19:09.330 に答える
0

ローカリゼーションがドメイン/アプリケーションの重要な部分である場合は、それを第一級市民にして、それが属する場所に注入する必要があります。「DDDは、ドメインオブジェクトに依存関係があってはならないと言っている」とはどういう意味かわかりません。説明してください。

于 2012-04-13T00:38:01.527 に答える
0

ドメインモデルオブジェクトに内部依存関係を追加しないようにするのは正しいことです。

より良い解決策は、次のようなサービスメソッド内でアクションを処理することです。

public class EmployeeServiceImpl implements EmployeeService {

   public void ClockEmployeeIn(Employee employee) throws InvalidOperationException {
      if (employee.isTerminated()) {
          // Localize using a resource lookup code..
          throw new InvalidOperationException("Error_Clockin_Employee_Terminated");      
      }       
      employee.setClockedInAt(DateTime.Now);
   }
}

次に、クロックイン呼び出しを行うポイントでDIフレームワークを使用してサービスを注入し、サービスを使用してドメインオブジェクトをビジネスロジックの変更から隔離できます。

于 2014-08-29T03:53:04.393 に答える