3

私はまだ DDD の初心者であり、CQRS の初心者であることは認めます。また、DDD や CQRS がすべての問題に対する適切なアプローチではない可能性があることも認識しています。それにもかかわらず、私はプリンシパルが好きですが、現在のプロジェクトのコンテキストでいくつか質問があります.

ソリューションは、現在の構成に基づいてパフォーマンス データを生成するシミュレータです。管理者は、シミュレーションの仕様を作成および変更できます。テスターはいくつかの環境条件を設定し、シミュレーターを実行します。結果がキャプチャされ、集計され、レポートされます。

このソリューションは、それぞれ独自のユース ケース、ドメイン ロジック、およびサポート データ構造を持つ 3 つのコンポーネント領域で構成されます。その結果、モジュラー設計は、ロジックを分離し、関心を分離する方法として魅力的に見えます。

  1. 最初の領域は、ユーザーが仕様を作成および変更できるようにする管理面です。これは、CRUD を多用する「モジュール」になります。
  2. 2 番目の領域は、シミュレーションを実行するためのものです。ドメイン モデルは最初の領域に似ていますが、編集に便利なモデルを提供するのではなく、シミュレーションを実行するために最適化されています。
  3. 3 番目の領域はレポートです。
このことから、私は 3 つのバウンディング コンテキストを持っていると信じています。アプリケーションへの 3 つの明確なエントリ ポイント、3 つのドメイン ロジック セット、およびドメイン ロジックをサポートする 3 つの異なるデータ モデルがあります。

私の最初の本能は、これらの方針に従い、各領域のドメイン層をカプセル化する 3 つのモジュール (アセンブリ) を作成することです。また、3 つの別個のデータベースを使用する必要がありますか? 書き込みと読み取りをサポートするために 3 つ以上でしょうか?

これはCQRSに適しているかもしれませんが、どうすればよいかわかりません。CQRS は、データを移動する一連のバックエンド プロセスを提案しているように思えます。しかし、それが事実であり、データの永続性が (DDD が示唆するように) 横断的である場合、データ アクセス コードはすべてのドメイン オブジェクトを認識する必要があるのではないでしょうか? もしそうなら、別々のモジュールを持つことには利点がありますか?

最後に、先ほど言い忘れたことは、仕様は発行されるまでは「ドラフト」と見なされ、その後シミュレーションに使用できるようになるということです。私の PublishingService は、SpecificationPublishedEvent に応答するときに、仕様を読み取り、モデルを変換し、実行のために永続化できるように、最初と 2 番目の領域の両方のドメイン モデルの知識を持っている必要があります。これは、結局のところ、3 つの境界コンテキストがないと思わせてくれます。それとも、私の分析で何かが欠けていますか?

4

1 に答える 1

1

このためのモジュラー UI があるかもしれませんが、あなたが説明しているものに 3 つの別々のドメインがあるとは思えません。

まず、CQRS では、レポートはドメイン モデルに直接関係するものではなく、レポート用に最適化されたドメインの状態を提示する役割を担う、分離された読み取りモデルの側面です。

第二に、ドメイン内でさまざまなことが起こっているからといって、必ずしもそれらを互いに切り離す理由にはなりません。青い DDD の本を読んで、BC がどのようなものかをもう少しよく理解してください。

私はあなたのドメインを十分に理解していませんが、いくつかの一般的な提案をしようと思います.

PublishingService について話したことから始めます。CreateNewSpecification、UpdateSpecification、および PublishSpecification のようないくつかのコマンドを使用する仕様集約ルートが表示されます。

イベントは似ていて、おそらく冗長に感じます: SpecificationCreated、SpecificationUpdated、SpecificationPublished。これはひどいことですが、CRUD を多用するモデルにはあま​​り興味深い動作がありません。また、この集計でモデル/スキーマの変更を処理する自動化された方法を見つけることをお勧めします。これは、コード生成を使用しない場合、またはあなたを必要としない動的な *強調されたテキスト* の方法で変更を処理する場合に面倒です。毎回新しいイベントを作成します。

また、CRUD が非常に重いため、このような集約ルートにはイベント ソーシングを使用しないことを検討することもできます。

あなたが説明する2番目のことは、仕様に基づいて実行され、そのシミュレーション中にデータを生成するシミュレーションを開始することについてのようです(私は思います)。イベント ドリブン アーキテクチャは、データを生成するプロセスからレポート データの更新を分離するのに適しています。これは、処理するデータを大量に生成する場合に大きなメリットがあります。

ただし、シミュレーションが必ずしもイベント ソーシングの恩恵を受ける種類の AR であるとは思えません。いくつかの理由から:

  1. シミュレーションは、StartSimulation のようなコマンドを 1 つだけ実行します。
  2. シミュレーションは、シミュレーションの内部で何が起こっているかを表すイベントを生成します。
  3. シミュレーションは、シミュレーションの現在の状態に依存する可能性のある他のコマンドを受け取ることはないようです
  4. シミュレーションは、複数のクライアント/ユーザーによって同時に操作されることはありません。指摘したように、実際にはまったく操作されません。

一般に、ドメイン モデリングは個々のプロジェクトに非常に固有であるため、ドメイン モデルの構築に必要なすべての情報を提供することは困難です。これは、ユーザーのニーズと、ユーザーがソフトウェアで解決しようとしている問題を理解するために多くの時間を費やした結果としてもたらされます。彼らのプロセスへの洞察を深めるにつれて、それはおそらく複数の改良を経るでしょう。

于 2011-06-07T17:49:45.777 に答える