混在したモデリングパラダイムの中で学ぶ重要なこと - Qiita
このエントリーは、 「ドメイン駆動設計 #1 Advent Calendar 2018」の2４日目の記事です。 23日目は、@smdmts さんの「ユビキタス言語と境界付けられたコンテキストを構築する目的とは」でした。 DDD本で触れられている、モデリングパラダイムについて考えを晒します。 まずはモデリングパラダイムについて考えましょう。 目的 「モデリングパラダイム」という言葉をどういう意味を持つのでしょうか。それは、以下の二つの単語で構成されます。 モデリング 広義の意味での模型（モデル）を組み立てる事を言う。 パラダイム ある時代のものの見方・考え方を支配する認識の枠組み。 「モデルを組み立てるための認識の枠組み」と考えてよいでしょう。 DDD本の用語解説では、以下の説明があります。モデリングの「枠組み」や「スタイル」と解釈して問題なさそうです。 ドメインにおける諸概念を切り取る特定
ドメインオブジェクトを中心としたClean Architecture のためのレイヤー構成 - Qiita
ドメインオブジェクトを中心としたClean Architectureは、どういうレイヤー構成にするとよいか、簡単にまとめてみた。 イメージ たぶん、こんな感じになるはず。通常は円状に表現するが、わかりにくいので層状に書いてみた。 赤い部分の層は、直接依存の方向が上から下です。グレー部分の層は、契約だけが定義された独立した層で、ユースケース層やインターフェイス層から依存できるものとします。 インターフェイス（アダプタ）層 内外とのデータ形式の変換が主な役割 コントローラ、プレゼンター（内部から外部へデータ形式を変換する責務）,ゲートウェイ(外部と通信する責務。DBやRPC) ユースケース層 アプリーケーション層ともいう アプリケーション固有のビジネスルールをカプセル化する ドメイン層 Clean Architecture本では、中心にはエンティティとだけ書かれているが、DDDでは中心はドメイ
ドメインオブジェクトの責務について - Qiita
設計するとき、「このオブジェクトの責務は何だろうか？」とか「この責務に名前をつけるなら何か？」とか、責務について考えることがよくあります。そもそもその責務とは何か、という根源的な疑問について再確認すると共に、ドメイン駆動設計の観点からドメインオブジェクトの責務についても考えてみたいと思います。 責務とは 困ったときの古典引用。もう絶版になった、オブジェクトデザインという、書籍を紐解いてみましょう。DDDからの引用が多い書籍で、DDDの設計スタイルは、この書籍で紹介する「責務駆動設計(responsibillity-driven design)」の原則に従うことが大きいとされています。 この書籍によると、「責務」には以下が含まれるそうです。 「4.1 責務とは何か」 オブジェクトが行う動作 オブジェクトが持つ知識 オブジェクトが他に影響を与える主要な判断 これらの言葉を身近な言葉で置き換える
リードモデルのN+1問題とCQRS - Qiita
背景 集約とリポジトリなどをアプリケーションサービスやコントローラから呼び出し、書き込みや読み込みの要求を実装することがよくあります。ほとんどの場合、トランザクション整合性の観点から考えると、書き込み要求は集約単位になりますが、読み込みは結果整合性も含めると、複数種の集約を合成した、いわゆるリードモデルを返すことが多いです。この記事では、このリードモデルに起こるN+1問題とCQRSの関連性についてまとめたいと思います。 リードモデルを返す処理 みなさんは、どのようにしてリードモデルを構築していますか？ いろいろな方法がありますが、ここでは以下に観点を絞ってみたい。 複数種のリポジトリを使って集約を取得し、リードモデル用DTOに詰め直す リポジトリを使わず、ストレージに対応したDAOで、JOINするような問い合わせを行う 対象のドメイン 話をわかりやすくするために、想定のドメインが必要ですね
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Scala.js ウェブフレームワーク Facade 調査(2019年4月版) - Qiita
ID生成方法についてあれこれ - Qiita
ドメインもしくはドメインモデルという概念が登場する書籍一覧
