.net - イベント ソーシングを使用したドメイン モデル

Question

ばかげた質問ですが、イベント ソーシングを使用する場合、なぜドメイン モデルが必要なのでしょうか。

私は（もちろんイベントバス）と

• それぞれが基本的な検証後にコマンドを送信するビジネス オペレーションを含むアプリケーション サービス
• コマンドを受信するコマンド ハンドラは、追加のコマンド検証を実行し、イベントを発行します。
• イベントを処理し、読み取りモデルを更新し、イベントをリポジトリ (イベント ソース) に保存するイベント ハンドラー
• 読み取りモデルを提供する読み取りモデル サービス
• 読み取りモデル サービスから読み取りモデルを使用するフロント エンド (UI またはその他)...およびビジネス オペレーションにアプリケーション サービスを利用します。

なぜ集約ルートとドメイン エンティティが必要なのですか? 追加のレイヤーの機能は何ですか?

Answer 1

あなたはそうしない。

ドメイン駆動設計とは、ドメイン エキスパートのユビキタス言語を使用してソフトウェアをモデリングすることです。そのモデルは「リレーショナル」モデルである場合もありますが、コマンドとイベントのモデルである場合もあります。

最近のインタビューで、Eric Evansは、戦術的なパターン (集約ルート、リポジトリ、抽象ファクトリ) などを強調せずに、代わりに境界コンテキストなどのモデリングへのアプローチを強調したいと説明しています。

彼はまた、CQRS + イベント ソーシングが DDD をまったく新しい視点に導いた方法についても説明しています。多くの点で、戦術的パターンは過去の名残です。過去には、真剣に受け止めるためにはすべてが OOP であり、基礎となるリレーショナル データベースが必要でした。あの時もそうでしたが、今はこうです。

Answer 2

EventSourcing は、アプリケーションの状態を保存する方法を簡単に選択できます。特定の問題を解決していない場合は、おそらくドメインのモデルは必要なく、単純なCRUDアプリケーションを作成するだけで済みます。ドメイン モデルは、アプリケーションが特定のビジネス上の問題を解決するドメインの単純化された抽象化です。ドメイン モデルは、あなたとチーム メイト、ドメインの専門家との間でコミュニケーションを取るためのツールです。この優れた本を読むか、このドメイン駆動設計の短い紹介をダウンロードすることをお勧めします。