DDDで設計するならCQRSの利用を検討すべき - Qiita

タイトルに書かれていることで全てなのですが、DDDとCQRSの併用について強調している日本語の情報が少ないので、軽くまとめておきます。 CQRS+DDD CQRS(コマンドクエリ責務分離)とは、サーバの機能を「コマンド」（副作用あり）と「クエリ」（副作用なし）で完全に分けちゃおう、という考え方です。そもそも「コマンド」と「クエリ」ではあらゆる要件が異なります。 一貫性： 「コマンド」は整合性のある処理が必要、「クエリ」はあまり気にする必要なし ストレージ： 「コマンド」側は正規化してデータを保存したい、「クエリ」側は非正規な方が効率的 スケーラビリティ： 「コマンド」は全体の負荷の中で占める割合が少ない、「クエリ」は負荷が大きい なので分けちゃうわけですが、 コマンド側 複雑なビジネスロジックが絡むので、ドメイン駆動が活躍 クエリ側 複雑なビジネスロジックがないので、ドメイン層はスキップ

[stockedge]

“初期の仕掛けとしてCQRSを導入しておく”

[yosuke_furukawa]

このDDD実践本が今だけ半額ですよ！

[Dai_Kamijo]

DDDで設計するならCQRSの利用を検討すべき on @Qiita — 上條　大 (@Dai_Kamijo) June 6, 2016 from Twitter https://twitter.com/Dai_Kamijo June 06, 2016 at 11:48AM via IFTTT

[teracy_junk]

『CQRS(コマンドクエリ責務分離)とは、サーバの機能を「コマンド」（副作用あり）と「クエリ」（副作用なし）で完全に分けちゃおう、という考え方です』

[izumin5210]

DDDのオーバーヘッドヤバい問題への対応

[iR3]

ふむふむ CQRS も勉強しないと

[sogood]

DDDで設計するならCQRSの利用を検討すべき - Qiita

[igrep]

“CQRS(コマンドクエリ責務分離)とは、サーバの機能を「コマンド」（副作用あり）と「クエリ」（副作用なし）で完全に分けちゃおう、という考え方”

[petite_blue]

CQRS(コマンドクエリ責務分離)

[sonesuke]

DDDで設計するならCQRSの利用を検討すべき (via @Pocket)

[kasumani]

DDDで設計するならCQRSの利用を検討すべき タイトルに書かれていることで全てなのですが、DDDとCQRSの併用について強調している日本語の情報が少ないので、軽くまとめておきます。 Tags: feedly, ifttt, recently read, saved for later from

[matsu7874]

DDDで設計するならCQRSの利用を検討すべき - Qiita

[efcl]

"CQRS(コマンドクエリ責務分離)とは、サーバの機能を「コマンド」（副作用あり）と「クエリ」（副作用なし）で完全に分けちゃおう、という考え方"

[kazuph1986]

"ある程度大きなシステムでないとDDDのオーバーヘッドはペイしないです"

[a_suenami]

参照系と更新系を分けようというのは考えたことあったけどCQRSという名前なのか。やってみたい。

[yass]

" CQRS(コマンドクエリ責務分離)とは、サーバの機能を「コマンド」（副作用あり）と「クエリ」（副作用なし）で完全に分けちゃおう、という考え方です。"

[graceful_life]

いい概念を聞いた

[ledsun]

知らんかった。更新系と参照系でアプリケーションを分ける。面白いアイデアだ。

[koyancya]

へー -> "CQRS(コマンドクエリ責務分離)とは、サーバの機能を「コマンド」（副作用あり）と「クエリ」（副作用なし）で完全に分けちゃおう、という考え方です。"

[mmm-mao]

“CQRSの和訳”

[tgk]

これは注目