Modelが基本的に必要な理由(翻訳)|TechRacho(テックラッチョ)〜エンジニアの「?」を「!」に〜|BPS株式会社エンジニアの「?」を「!」に。原著者の許諾を得て翻訳・公開いたします。Blog日本語タイトルは内容に即したものにしました。Modelとも呼ばれ、データの読み出しをデータの書き込みから分離します。Modelと対になります。Sourcing)は一定のメリットを得られる優れた技法ですが、1つ大きな制約があります。現在のステートの概念を簡単に得られないため、たとえば出荷可能数が10個以下の全製品が欲しいという問い合わせの回答を得るのが簡単ではありません。ID=1のProductとしてイベントのProduct-1ストリームを読み出し、それを用いてこの製品の現在のステートを再構成して、その製品の出荷可能数が10個より少ないかどうかという回答を得ることも一応可能ですが、すべての製品について回答を得るには、すべてのProduct-*ストリームを列挙し、全製品の保存済みドメインイベントをすべて処理する必要があります。この操作には膨大な時間とコストがかかるでしょう。普段の業務で目にする次のユースケースはいずれも困難が少し増すでしょう。他にいくらでも考えられます。してこうなってしまうのでしょうか。その理由は、エンティティ(Entity)や集約(Aggregate)がイベントソーシングされると、オブジェクトのリポジトリへの問い合わせ方法が1つに限定されてしまうためです。その方法とはすなわちfind_by_idです。他の場所(他のエンティティなど)で得たこのidが、その場所への参照(またはUIからの参照、APIからの参照、リクエストからの参照)を持つことは理解できるので、次のように書けます。ProductRepository.find_by_id(id)このリポジトリは、自分が読み取るべきイベントのストリーム(Product-1など)を認識し、それらのイベントがProductのインスタンスに適用されることで1つの製品の現在のステートが再構成されます。