ID生成方法についてあれこれ - QiitaHelp us understand the problem. What are the problem?
リードモデルのN+1問題とCQRS - Qiita
背景 集約とリポジトリなどをアプリケーションサービスやコントローラから呼び出し、書き込みや読み込みの要求を実装することがよくあります。ほとんどの場合、トランザクション整合性の観点から考えると、書き込み要求は集約単位になりますが、読み込みは結果整合性も含めると、複数種の集約を合成した、いわゆるリードモデルを返すことが多いです。この記事では、このリードモデルに起こるN+1問題とCQRSの関連性についてまとめたいと思います。 リードモデルを返す処理 みなさんは、どのようにしてリードモデルを構築していますか？ いろいろな方法がありますが、ここでは以下に観点を絞ってみたい。 複数種のリポジトリを使って集約を取得し、リードモデル用DTOに詰め直す リポジトリを使わず、ストレージに対応したDAOで、JOINするような問い合わせを行う 対象のドメイン 話をわかりやすくするために、想定のドメインが必要ですね
混在したモデリングパラダイムの中で学ぶ重要なこと - Qiita
このエントリーは、 「ドメイン駆動設計 #1 Advent Calendar 2018」の2４日目の記事です。 23日目は、@smdmts さんの「ユビキタス言語と境界付けられたコンテキストを構築する目的とは」でした。 DDD本で触れられている、モデリングパラダイムについて考えを晒します。 まずはモデリングパラダイムについて考えましょう。 目的 「モデリングパラダイム」という言葉をどういう意味を持つのでしょうか。それは、以下の二つの単語で構成されます。 モデリング 広義の意味での模型（モデル）を組み立てる事を言う。 パラダイム ある時代のものの見方・考え方を支配する認識の枠組み。 「モデルを組み立てるための認識の枠組み」と考えてよいでしょう。 DDD本の用語解説では、以下の説明があります。モデリングの「枠組み」や「スタイル」と解釈して問題なさそうです。 ドメインにおける諸概念を切り取る特定
ドメインオブジェクトを中心としたClean Architecture のためのレイヤー構成 - Qiita
ドメインオブジェクトを中心としたClean Architectureは、どういうレイヤー構成にするとよいか、簡単にまとめてみた。 イメージ たぶん、こんな感じになるはず。通常は円状に表現するが、わかりにくいので層状に書いてみた。 赤い部分の層は、直接依存の方向が上から下です。グレー部分の層は、契約だけが定義された独立した層で、ユースケース層やインターフェイス層から依存できるものとします。 インターフェイス（アダプタ）層 内外とのデータ形式の変換が主な役割 コントローラ、プレゼンター（内部から外部へデータ形式を変換する責務）,ゲートウェイ(外部と通信する責務。DBやRPC) ユースケース層 アプリーケーション層ともいう アプリケーション固有のビジネスルールをカプセル化する ドメイン層 Clean Architecture本では、中心にはエンティティとだけ書かれているが、DDDでは中心はドメイ
続: DDDのリポジトリのインターフェイスをどのように設計すべきか - Qiita
昔書いた記事ですが、今回は続編です。 DDDのリポジトリのインターフェイスをどのように設計すべきか 過去の実装は一旦捨てて書き直してみました。 scala-ddd-base/reboot 前回と比べて改善した点は以下です。 Try, Futureなどの個別の型向けのtraitを作らない IO用コンテキストをリポジトリメソッドから追い出した 型パラメータの数を減らす 型クラスとTagless Final 同期版、非同期版というようにトレイトや実装を分けていくと複雑になりがちなので、以下のようしました(実装は???ですが、詳細はgithubを参照してください) 型パラメータはM[_]だけになります。高階型というやつです。ID型は抽象型メンバーにすることで型パラメータの数を減らしました。 trait UserAccountRepository[M[_]] extends AggregateSin
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ドメインもしくはドメインモデルという概念が登場する書籍一覧
DDDリポジトリを楽に実装するライブラリ - Qiita
