リードモデルのN+1問題とCQRS - Qiita
背景 集約とリポジトリなどをアプリケーションサービスやコントローラから呼び出し、書き込みや読み込みの要求を実装することがよくあります。ほとんどの場合、トランザクション整合性の観点から考えると、書き込み要求は集約単位になりますが、読み込みは結果整合性も含めると、複数種の集約を合成した、いわゆるリードモデルを返すことが多いです。この記事では、このリードモデルに起こるN+1問題とCQRSの関連性についてまとめたいと思います。 リードモデルを返す処理 みなさんは、どのようにしてリードモデルを構築していますか？ いろいろな方法がありますが、ここでは以下に観点を絞ってみたい。 複数種のリポジトリを使って集約を取得し、リードモデル用DTOに詰め直す リポジトリを使わず、ストレージに対応したDAOで、JOINするような問い合わせを行う 対象のドメイン 話をわかりやすくするために、想定のドメインが必要ですね
ドメインロジックはドメインオブジェクトに凝集させる - Qiita
こんにちは。 最近、こんなツイートしたのですが、ドメインオブジェクトではなくアプリケーションサービス1などにドメインロジックが書かれてしまうことがあります。 アプリケーションサービスはドメインロジックを配置する場所ではない、それはドメインオブジェクトの役割。アプリケーションサービスは進行役。ここを間違うから簡単にドメインモデル貧血症になってしまうんだと思います。 — かとじゅん (@j5ik2o) August 18, 2019 最近、以下の書籍(以下 増田本)をマジメに読み直しました(笑)。ドメインモデル貧血症2を回避して、ドメインロジックをドメインオブジェクトに凝集させる方法に関して、増田本にいろいろ書いてあったので、そのエッセンスと僕の考察を交えて解説したいと思います3。 詳しい内容は以下の増田本を読んでください！ コード例はScalaですが難しい表現がないので、Scalaが分からな
ドメインオブジェクトの責務について - Qiita
設計するとき、「このオブジェクトの責務は何だろうか？」とか「この責務に名前をつけるなら何か？」とか、責務について考えることがよくあります。そもそもその責務とは何か、という根源的な疑問について再確認すると共に、ドメイン駆動設計の観点からドメインオブジェクトの責務についても考えてみたいと思います。 責務とは 困ったときの古典引用。もう絶版になった、オブジェクトデザインという、書籍を紐解いてみましょう。DDDからの引用が多い書籍で、DDDの設計スタイルは、この書籍で紹介する「責務駆動設計(responsibillity-driven design)」の原則に従うことが大きいとされています。 この書籍によると、「責務」には以下が含まれるそうです。 「4.1 責務とは何か」 オブジェクトが行う動作 オブジェクトが持つ知識 オブジェクトが他に影響を与える主要な判断 これらの言葉を身近な言葉で置き換える
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
