2

分散アーキテクチャ（クライアントサーバー）があるとしましょう。クライアント側にはServerEntityクラスがあり、クライアント側にはそのClientEntityクラスがあります。ClientEntityがServerEntityにデータを要求するだけでよいのです。私は最近DDDアプローチを学び始めましたが、実際にはドメインイベントが好きなので、それを使いました。これが、将来の実装に対する私の単純な期待です。

  1. ClientEntityはコマンドRequestDataCommandを作成し、それを公開します（たとえば、MessageBusを介して）
  2. クライアントのApplicationLayerはこのコマンドを取得し、それを接続してサーバーに送信します
  3. サーバーのApplicationLayerはコマンドを受信し、コマンドをMessageBusにプッシュします
  4. ServerEntityはコマンドを受信し、いくつかのデータを含むドメインイベントを公開します
  5. サーバーのApplicationLayerはこのイベントを取得し、接続してクライアントに送信します
  6. クライアントのApplicationLayerはイベントを受信し、コマンドをDomainEventManagerにプッシュします
  7. ClientEntityはイベントにサブスクライブされ、受信すると内部状態が変更されます。

上記のアプローチの欠点は、数十のコマンドクラスが作成されることです。

一方、別のオプションがあります。IRequestDataServiceのようなドメインサービスインターフェイスを作成し、ClientEntityの依存関係として作成します。したがって、コマンドクラスを作成してメッセージバスに渡す必要はありません。IRequestDataServiceから適切なメソッドを呼び出すだけです。サーバーからの応答は、前の例のようにドメインイベントとして受信されます。

2番目のアプローチの欠点は、コマンドを送信するためだけにサービスを使用することです。これは、私のビジョンでは同期操作のみを実行する必要があります。

どちらのアプローチが優れているのでしょうか。クライアントサーバー通信について正しい方法だと思いますか。

4

1 に答える 1

0

あなたの RequestDataCommand は、私にはコマンドのようには見えません。

コマンドは、システムの状態を変更する UL を使用した命令的なディレクティブです。データを要求しても状態は変わらないため、コマンドであってはなりません。

あなたの2番目のアプローチは、同様の問題に悩まされています。IRequestDataService への呼び出しは、サーバーの状態を変更してはなりません。状態の変化がないということは、少なくとも「通常の」DDD では、イベントが発生しないことを意味します。

私の印象では、インフラストラクチャ (イベント、メッセージ バスなど) を使用して、すべきではないことをしようとしているようです。

私の意見では、データを読み取るためのより良いオプションは、ほとんどのドメイン ロジックをバイパスし、最も単純で直接的な方法でデータを読み取ることです。CQRS を見てみましょう ( http://martinfowler.com/bliki/CQRS.htmlが良いスタートです)

于 2016-01-11T12:40:52.490 に答える