まだ CQRS 実装の実験を掘り下げているので、ブログをゼロからやり直し、サンドボックスとして使用することにしました。
境界付けられたコンテキストについてよく読んでいますが、これはすべての中で最もデリケートなアプローチであり、説明して実際のプロジェクトに適用するのが最も難しいと思われます。
幸いなことに、ここでの私のドメインは非常に単純です ;-)
さまざまな境界付けられたコンテキストを特定し、これらの各コンテキストでどのモデルが集約ルートになるかを判断しようとしています。
ドメイン ルールは非常に単純です。
ライター がブログ投稿を作成するとき、投稿を保存するカテゴリを選択する必要があり、投稿の可視性を向上させるためにオプションで複数のタグを選択できます
読者がブログにアクセスすると、カテゴリ別またはタグ別にブログ投稿を閲覧できます
これらのルールだけで、すでにいくつかの境界付けられたコンテキストが得られていますね。
ユーザー (ライター) が投稿コンテキストを構成します。これらのコンテキストでは、投稿は集約ルートです
ユーザー（読者）はカテゴリー別に投稿を閲覧します。これらのコンテキストでは、カテゴリは集約ルートです。
ユーザー（読者）はタグで投稿を閲覧します。この文脈では、よくわかりません... ;-)
私は物事を正しく考えていますか？
私が (正しい) とすれば、これを実装する際に、さまざまなオブジェクトと関係を作成する責任があるのは誰でしょうか?
たとえば、ユーザーが新しいブログ投稿を作成するコンテキストを考えてみましょう。タグ インスタンスを作成する場所と、書き込みモデルで投稿とそのタグの間の関係を作成する必要があるかどうかについて、まったく手がかりがありません。同じことがカテゴリにも当てはまります。わかりません:p
また、境界付けられたコンテキストは特定のモデルを意味しますか? 境界付けられたコンテキストごとに、(書き込みモデルで) 異なるオブジェクト グラフを持つことを意味しますか?
これを頭の中で明確に理解するには、脳波が必要です;-)
新しい投稿を追加するために、これまでのところ、コントローラーはコマンドバスに「ComposeCommand」を処理するように要求し、ハンドラー (PostService) は新しい「Post」インスタンスを作成し、その上で構成メソッドを呼び出し、最後に書き込み永続性に保存するように要求します。新しい投稿。
Post::compose() メソッドは、読み取りモデルがリッスンしてデータを更新する「PostComposedEvent」イベントを発生させます。
この中で、「カテゴリー」と「タグ」の導入方法がわかりません。
ありがとう。