3

私は DDD と Hexagonal アーキテクチャを学んでいます。基本は理解できたと思います。ただし、解決方法がわからないことが 1 つあります。ユーザーにデータを表示するにはどうすればよいでしょうか。

たとえば、いくつかの機能を備えた Worker エンティティ (一部のメソッドによってエンティティが変更されます) と WorkerRepository を持つ単純なドメインを取得したので、Worker を永続化できます。ドメインを操作するためのいくつかのコマンドとコマンド バス (ワーカーの作成、作業時間の更新、変更の永続化など) を含むアプリケーション層と、WorkerRepository と GUI アプリケーションの実装を含むインフラストラクチャ層を取得しました。

このアプリケーションでは、すべてのワーカーにデータの一部を表示し、それらを変更できるようにしたいと考えています。データを表示するにはどうすればよいですか?

  1. WorkerRepository の実装への参照を与えることができます。この方法では、コマンド バスをスキップして新しいワーカーをリポジトリに挿入できるため、これは良い解決策ではないと思います。コマンドバスを介してすべての変更が行われるようにします。
  2. では、WorkerRepository を WorkerQueryRepository と WorkerCommandRepository に分割し (CQRS に従って)、WorkerQueryRepository のみを参照します。リポジトリは、それらを変更するメソッドを持つ Worker エンティティを返すため、これはまだ良い解決策ではありません。これらの変更はどのように永続化されますか?
  3. 2 種類のリポジトリを作成する必要がありますか? 1 つはドメインとアプリケーション層で使用され、もう 1 つはデータを外部に提供するためだけに使用されます。2 つ目は、完全な Worker エンティティを返すのではなく、GUI が必要とするデータのみを含む WorkerDTO のみを返します。このように、GUI でワーカーを変更する方法は他になく、コマンド バスを使用するだけです。

3番目のアプローチは正しい方法ですか？または、変更がコマンドバスを通過する必要があることを強制するのは間違っていますか?

4

1 に答える 1

2

2 種類のリポジトリを作成する必要がありますか? 1 つはドメインとアプリケーション層で使用され、もう 1 つはデータを外部に提供するためだけに使用されます。2 つ目は、完全な Worker エンティティを返すのではなく、GUI が必要とするデータのみを含む WorkerDTO のみを返します。

それが CQRS のアプローチです。それはかなりうまくいきます。

グレッグ・ヤング (2010)

CQRS は、以前は 1 つしかなかったオブジェクトを 2 つ作成するだけです。分離は、メソッドがコマンドであるかクエリであるかに基づいて行われます (コマンドとクエリの分離で Meyer が使用するのと同じ定義です。コマンドは状態を変更する任意のメソッドであり、クエリは値を返す任意のメソッドです)。

あなたが提案する WorkerDTO の現在の用語は「プロジェクション」です。多くの場合、複数あります。つまり、GUI でワーカーのビューごとに個別の投影を行うことができます。(これには、ビューを簡単にするというきちんとした副作用があります。データは既に便利にフォーマットされているため、与えられたデータについて考える必要はありません)。

これを考える別の方法は、「書き込み専用」表現 (集約) と「読み取り専用」表現 (投影) があるということです。どちらの場合も、記録簿から (リポジトリを介して) 現在の状態を読み取り、その状態を使用して必要な表現を構築します。

読み取りモデルを保存する必要がないため、読み取り側ではリポジトリではなくfactoryを考えたほうがよいでしょう。(2009 年、Greg Young は同じ理由で「プロバイダー」を使用しました。)

2 つのオブジェクトを分離する最初のステップを実行したら、それぞれの異なるユース ケースに個別に対処することができます。

たとえば、読み取りパフォーマンスをスケールアウトする必要がある場合は、記録簿を多数のスレーブ コピーに複製し、プロジェクション ファクトリをマスターではなくスレーブからロードするオプションがあります。または、別の永続ストア (キー値ストア、グラフ データベース、全文インデクサー) がより適切かどうかの調査を開始します。Udi Dahan はCQRS でこれらのアイデアの多くをレビューしていますが、違います(2015)。

「読み取りモデルは保存する必要はありません」は正しくありません。

正しいです; しかし、それはおそらく可能な限り明確で具体的ではありません.

読み取りモデルのインスタンス間の差異を説明するすべての情報が既に書き込みによってキャプチャされているため、読み取りモデルの永続的な表現を作成する必要はありません。

読み取りモデル (またはその表現)をキャッシュして、多くのクエリにわたって読み取りモデルを作成する作業を償却できるようにすることがよくあります。また、さまざまなトレードオフにより、キャッシュされた表現を永続的に保存する必要があることが示される場合があります。

しかし、流星がやってきて読み取りモデルのキャッシュを破壊した場合、作業への投資は失われますが、情報は失われません。

于 2016-05-04T00:07:08.867 に答える