この記事では、CQRSの入門として、軽量CQRS、別名クエリモデルについて解説します。 DDDの参照系処理で発生する課題 解決策 CQRSのメリット、デメリット 実装時の注意事項 部分的導入について なぜQueryServiceの定義がUseCase層なのか 整合性をどうやって担保するのか よくある誤解 データソースを分ける必要があるのか イベントソーシングとの関係 過去資料との繋がり もっと詳しく知りたい方は 現場での導入で困ったら DDDの参照系処理で発生する課題 DDDで定義されている実装パターンを使っていると、基本的には永続化層との入出力はRepositoryを使うことになります。 更新系の処理ではEntityやValueObjectでドメインの知識を表現し、Repositoryを使って集約単位で永続化するという構成をとると、非常にメンテナンス性の良いものになります。 参考過去記事
![CQRS実践入門 [ドメイン駆動設計] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/6a4c5f38eeedeba9c1ce48808acf9444e3af18a4/height=288;version=1;width=512/https%3A%2F%2Fcdn.image.st-hatena.com%2Fimage%2Fscale%2F1d248988cd31ca6b1592926c741fcd58a4621157%2Fbackend%3Dimagemagick%3Bversion%3D1%3Bwidth%3D1300%2Fhttps%253A%252F%252Fcdn-ak.f.st-hatena.com%252Fimages%252Ffotolife%252Fl%252Flittle_hands%252F20191202%252F20191202061944.png)
タイトルに書かれていることで全てなのですが、DDDとCQRSの併用について強調している日本語の情報が少ないので、軽くまとめておきます。 CQRS+DDD CQRS(コマンドクエリ責務分離)とは、サーバの機能を「コマンド」（副作用あり）と「クエリ」（副作用なし）で完全に分けちゃおう、という考え方です。そもそも「コマンド」と「クエリ」ではあらゆる要件が異なります。 一貫性： 「コマンド」は整合性のある処理が必要、「クエリ」はあまり気にする必要なし ストレージ： 「コマンド」側は正規化してデータを保存したい、「クエリ」側は非正規な方が効率的 スケーラビリティ： 「コマンド」は全体の負荷の中で占める割合が少ない、「クエリ」は負荷が大きい なので分けちゃうわけですが、 コマンド側 複雑なビジネスロジックが絡むので、ドメイン駆動が活躍 クエリ側 複雑なビジネスロジックがないので、ドメイン層はスキップ
書き込みと読み込みのどちらに力を入れているかは、ストレージエンジンによって異なります。たとえば昔ながらのリレーショナルデータベースは、外部キーなどの制約を使ってデータの整合性をうまく制御できるようになっています。一方でNoSQLデータベースは、スループットとスケーラビリティを確保するために、そういった組み込みのガードレールをはずしてしまいました。データ層においても、どちらか一方に特化した最適化をすることがあります。たとえば、あらかじめ計算済みの値を保持しておけば、「一日あたりのサイト訪問者数」などの読み込み操作を効率よく行えるでしょう。ストレージソリューションのメーカーはどこも、「うちのプロダクトならあらゆるニーズを満たせます」などと自社製品の機能を自慢します。しかし実は、昔ながらのCRUDモデルに沿ってストレージエンジンを選んでデータ層を設計した時点で、さまざまな関心事の間で何らかの妥協
より詳細なCQRSに関する資料はこちら https://little-hands.hatenablog.com/entry/2019/12/02/cqrs 参考資料：http://little-hands.hatenablog.com/entry/jjug2017fall 社内新規プロダクトでDDD, CQRSの思想をベースとしたアーキテクチャを構築し、コマンド(更新系処理)ではSpring Data JPA(Hibernate)を、クエリ(参照系処理)ではjOOQを採用しました。 結果としてそれぞれのORMの良いところを生かした組み合わせのアーキテクチャが構築できたので、その経緯と得られた知見についてお話ししたいと思います。 以下のようなトピックを考えています。 ・CQRSの定義とメリットデメリット ・DDD,CQRSを検討するにあたってのORMの選定ポイント ・構築したアーキテクチャ
AWS データベースブログの記事 「Amazon DynamoDBによる CQRSイベントストアの構築」 を勝手に読み解く
MCPを活用した検索システムの作り方/How to implement search systems with MCP #catalks
新版は https://www.slideshare.net/koichiromatsuoka/ddd-x-cqrs-orm こちらご参照ください！ アーキテクチャの話はこちらのブログ記事でも書いています。 http://little-hands.hatenablog.com/entry/2017/10/04/231743 http://little-hands.hatenablog.com/entry/2017/10/11/075634
PHPではじめるCQRSっぽいやつ
PHPerKaigi2021のアンカンファレンスで使ったものです。 PHPカンファレンス仙台2019の再演です。
AWS データベースブログの記事 「Amazon DynamoDBによる CQRSイベントストアの構築」 を勝手に読み解く
Greg Young流CQRS - Mark Nijhof - Digital Romanticism
この記事はMark Nijhof氏のブログ記事「CQRS à la Greg Young」を氏の許可を得て翻訳したものです。（原文公開日：2009/11/11） この記事は以前のブログである"blog.fohjin.com"にて公開していたものです。 以前、2日間の講習を受けた時に、ビールを飲みながらGreg Young氏とドメイン駆動設計について語るという幸運に恵まれたことがあります。その時の話題は専ら、コマンドクエリ責務分離（CQRS:Command and Query Responsibility Segregation）パターンに関するものでした。Gregは、Eric Evans氏が著作において説明したドメイン駆動設計を受け継ぎ、主に技術的な実装を進化させています。コマンドクエリ分離（CQS）は元々Bertrand Meyer氏によって考案されたもので、オブジェクトのレベルで適用さ
そろそろイベントソーシング・CQRSを使ってみてもいい頃なんじゃない？ いろんな面で準備が整ってきています... イベントソーシングの良さを伝えつつ、Xでイベントソーシングやドメイン駆動開発について話している方、また吉祥寺.pm36参加予定の方を対象にしたアンケート結果を発表します！ 1.…
はじめに こんにちは、計測プラットフォーム部バックエンドチーム、テックリードの児島（@cozima0210）です。この記事では、ZOZOSUITとZOZOMATの違いにより生じたバックエンド開発における課題と、その解決のためにCQRSアーキテクチャを採用した経緯、そしてその実践について紹介します。 ZOZOSUITとは ZOZOSUITは、2017年に発表した全身の計測を目的としたツールです。現在も計測機能は提供されていますが、新規の販売は終了しています。現在、ZOZOSUITの計測データは、マルチサイズ商品の開発に活かされています。 ZOZOMATとは ZOZOMATは、2019年に発表した足の計測を目的としたツールです。足の計測データから、足型診断や推奨サイズの提案に活用されています。今年の2月にリリースし、ZOZOSUITに続く計測技術として、とても注目をいただきました。 計測プラッ
DynamoDBによるOutboxパターンとCDCを用いたCQRSアーキテクチャの実装〜ZOZOMOでの取り組み - ZOZO TECH BLOG
こんにちは。ブランドソリューション開発部プロダクト開発ブロックの岡元です。普段はFulfillment by ZOZOとZOZOMOのブランド実店舗の在庫確認・在庫取り置きサービスの開発、保守をしています。 本記事では、ブランド実店舗の在庫確認・在庫取り置きサービスで実装したCQRSアーキテクチャについて紹介させていただきます。 CQRSの実装においては、データベース（以下、DB）分割まで行い、コマンド側DBにはAmazon DynamoDB（以下、DynamoDB）、クエリ側DBにはAmazon Aurora MySQL（以下、Aurora MySQL）を用いています。また、コマンド側DBとクエリ側DBの橋渡しを担うメッセージングにおいてはOutboxパターンと変更データキャプチャを用いました。DBとメッセージングシステムへの二重書き込みを避けることで障害などのタイミングで顕在化する潜在
翻訳 「DDD, Hexagonal, Onion, Clean, CQRS…これらをどうやり遂げるのか？」 - tagoto web - confluence
We tried to load scripts but something went wrong. Please make sure that your network settings allow you to download scripts from the following domain: https://id-frontend.prod-east.frontend.public.atl-paas.net
CQRSはなぜEvent Sourcingになってしまうのか、まとめてみたいと思います。 なぜまとめるか、それはCQRSにとってEvent Sourcingはオプションだと誤解されている方が多いからです。この記事を書いてる本人も最初はそう思っていましたが、実際に開発・運用を経験してみるとCQRSにとってEvent Sourcingはほぼ必須で、認識を改めるべきだと気づきました。なので、原義に基づいたうえで、Event SourcingではないCQRSがなぜよくない設計になるのか解説します。 その前に松岡さんの記事について。 CQRSの領域ではモデルを完全に分ける 松岡さんの記事には”CQRSはモデルを完全に分ける必要はない”と書かれていますが、知識がないと誤解しがちですが文字のまま意味を取るといけません。こちらの言及は、システムのうち、モデルをC/Qに分割するCQRS領域とモデルを分割しな
CQRS設計パターンをモダナイズする
CQRSとは CQRS（Command Query Responsibility Segregation、コマンド・クエリ責務分離）は、ソフトウェアアーキテクチャパターンの一つで、つまりシステムのコマンド部分をクエリ部分から分離します。基本的な考え方は、データの書き込み操作（コマンド）と読み取り操作（クエリ）を異なるモデルで扱うことです。これにより、スケーラビリティ/パフォーマンス/セキュリティの観点で柔軟な設計が可能となり、クエリ要件に合わせて最適化が実現できます。 CQRSの基本構成としては、 コマンドモデル（書き込みモデル）：データの作成、更新、削除といった書き込み操作を担当します。このモデルは、データの整合性と一貫性を確保するために最適化されています。 クエリモデル（読み取りモデル）：データの読み取り操作を担当します。このモデルは、クエリのパフォーマンスを最大化するために最適化され
Flux is an application architecture designed by Facebook for their JavaScript applications. It was first introduced by Facebook in May 2014, and it has since garnered much interest in the JavaScript community. There are several implementations of Flux. Frameworks like Fluxxor keep to the original Facebook Flux pattern, but reduces the amount of boilerplate code. While other frameworks like Reflux
CQRSの和訳
DDDとCQRSについて DDD (Domain Driven Design = ドメイン駆動設計)が世間に知られるようになってきましたが、今度はDDDをさらにスケーラビリティにするCQRS (Command Query Responsibility Segregation = コマンドクエリ責務分離)が出てきました。 DDD提唱者の英語本の和訳版「エリック・エヴァンスのドメイン駆動設計」がAmazonにありますが、非常に分厚く高価です。概要をまとめた資料が「Domain Driven Design（ドメイン駆動設計） Quickly 日本語版 - InfoQ」から入手できます。 CQRSはデータベース設計とイベントソーシングも含めた壮大なWebアプリケーションのアーキテクチャですが、日本語の資料がまだ少ないです。CQRSを適用したアプリケーションを構築できるインフラがWindows Az
ビジネス ドメインの理解を反映するマイクロソフトサービスまたはコンテキスト境界ごとのドメイン モデルを設計する このセクションでは、複雑なサブシステムへの取り組みが必要な場合に実装する高度なマイクロサービスについて、またドメイン専門家の知識と絶えず変化するビジネス ルールに由来するマイクロサービスについて説明します。 このセクションで使用するアーキテクチャ パターンは、図 7-1 に示すように、ドメイン駆動設計 (DDD) とコマンドクエリ責務分離 (CQRS) の手法に基づいています。 図 7-1。 外部マイクロサービス アーキテクチャとマイクロサービスごとの内部アーキテクチャ パターンとの対比 ただし、ASP.NET Core Web API サービスの実装方法や、Swashbuckle または NSwag を使った Swagger メタデータの公開方法など、データ駆動型マイクロサービ
1. CQRS+EventSourcingをAkka Persistence を使って実装してみる。〜コツとハマりポイン ト〜 2016/03/16 Reactive Messaging Patternsプレ読書会 - CQRS、ESの基本を学ぶ - Satoshi Matsushita 2. 自己紹介 • Satoshi Matsushita @satoshi_m8a • Scala, Akka, DDD, フロントエンド, コンピュータビジョン, 機械学 習 • ゲヒルン株式会社 Python, Go, Erlang, Scala, OCaml, TypeScript 「Gehirn Infrastructure Services」 セキュリティ診断 • ECのシステムをAkka Persistenceを使って開発していた。 3. Akka + DDD 気運の高まり(1) • Scal
peing.net メッセージングシステムのお題のようです。面白そうなのでちょっと考えてみよう。 問題提起 集約候補が以下の3つ。 ユーザー 企業 スレッド メッセージ スレッド集約はメッセージを複数保持するようです。 1000件のメッセージを保持するスレッド集約を更新した際、1000件のアップデートが行われる スレッド集約内部で更新された属性を把握していない場合は、リポジトリでは全メッセージ分の更新となる。これを避けるための仕組みはどう実装するのか？ ということが指摘されている。まぁわかります。これはCQRS/ESなら解決できるよと言ってみる 問題の分析 で、僕ならどう考えて実装に落とすかつらつらまとめてみよう。CQRS/ES前提です。Akkaの成分は少なめでScalaの擬似コードで解説します。コードはコンパイルしてないので…おかしなところあるかも。 問題はスレッド集約がメッセージの集合
クエリについて説明します。 クエリによってデータが変更されることはありません。 代わりに、ドメイン ロジックを使用せずに、必要なデータを便利な形式で提示するデータ転送オブジェクト (DTO) を返します。 この個別の責任の分離により、システムの設計と実装が簡素化されます。 読み取りモデルと書き込みモデルを分離する 読み取りモデルを書き込みモデルから分離すると、データ書き込みとデータ読み取りに関する特定の問題に対処することで、システムの設計と実装が簡素化されます。 この分離により、明確さ、スケーラビリティ、パフォーマンスが向上しますが、トレードオフが生じます。 たとえば、オブジェクト リレーショナル マッピング (O/RM) フレームワークなどのスキャフォールディング ツールでは、データベース スキーマから CQRS コードを自動的に生成できないため、ギャップを埋めるためにカスタム ロジック
このスライドでは、RailsでCQRS/ESを実装する際のポイントやメリットについて解説しています。 イベントソーシングを導入することで、システムの状態変化を履歴として記録し、過去の状態を正確に再現できるようになります。これにより、バグの原因特定やデータの復元が容易になります。 また、CQR…
この記事は 弁護士ドットコム Advent Calendar 2020 19日目の記事です。12月19日の午前2時を過ぎて苛立ちがドアを叩くころです。 今年は上野学さんの単著『オブジェクト指向UIデザイン 使いやすいソフトウェアの原理』が発売され、OOUIという言葉が盛り上がっていますね。昨日のアドベントカレンダーの記事を書いた @shirauix さんともOOUIの話で盛り上がり、彼が主催で社内読書会も行われました。 さて、世間的にも社内的にもOOUIが盛り上がって読書会も開催されるなか、わたしは社内でひっそりと「タスクベースUI」の勉強会をやったのでした。 タスクベースUI？ 「タスクベースUI」という言葉は、先程の上野さんが盛んに言及することで最近有名になった言葉な気がします。 『オブジェクト指向UIデザイン』から引用します。 GUIのようにオブジェクトを起点として設計された操作モデ
CQRS Documents by Greg Young
CQRS Documents by Greg Young http://cqrsinfo.com 1 Content A Stereotypical Architecture | ステレオタイプなアーキテクチャ.................................. 3 Application Server | アプリケーションサーバ............................................................ 3 Client Interaction | クライアントの対話 ............................................................... 4 Analysis of the Stereotypical Architecture | ステレオタイプなアーキテクチャの分析 ..
bliki: CQRS
CQRS stands for Command Query Responsibility Segregation. It's a pattern that I first heard described by Greg Young. At its heart is the notion that you can use a different model to update information than the model you use to read information. For some situations, this separation can be valuable, but beware that for most systems CQRS adds risky complexity. The mainstream approach people use for i
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事について 先日 DDD-Community-Jp の DDD Talk MeetUp #2 というイベントでトーク枠にて参加させて頂き Flyweight DDD というアーキテクチャスタイルの提案とする一つのスライドを発表させて頂きました。 https://speakerdeck.com/hirodragon112/ddddao-ru-nita-miqie-renaifang-hezeng-ru-2ceng-plus-cqs-akitekutiya-flyweight-ddd ただ、本稿はこのスライドの「内容」とは全く関係あり
アンケート作成システムのサーバサイドをKotlin + Quarkus + Doma, CQRSで構築している話 - エムスリーテックブログ
エムスリー エンジニアの岩本です。 現在私の所属しているチームでは、以前作成したアンケートを作るためのシステムのサーバサイドリプレースを検討しています。 ちなみにクライアントサイドは下記のものです。 qiita.com 採用した技術 なぜQuarkus? SQLアクセスはDoma Domaの記述方法 Quarkus + Domaで見つかった問題 設計方針はCQRS まとめ We're hiring! 採用した技術 以前のサーバサイドはJavaで作られており、再利用可能な既存の資産もあるため、JVM系の言語を検討しています。 他のシステムではKotlin + SpringBootを使っているため同様の構成も考えられるのですが、 SpringBootが開発しているうちに重くなり、起動に数十秒かかるようになり開発スピードが遅くなってしまったことや 新しいものに挑戦したいという技術者の考えを重要視
All slide content and descriptions are owned by their creators.
2016 - 02 - 20 CQRSの小さな演習(1) 現実の問題 作ったもの 考えたこと システム開発とエンジニアリング ドメイン駆動設計 CQRSの小さな演習 仕事で業務向けのWebアプリケーション開発をしています。その中でもいろいろな問題がやはりあるのですが、特に大きな問題だなと思えることがあります。エンハンスや保守改修が続くと、もうなにがなんだったか分からなくなってしまうことです。私はもう20代でもなくて、記憶力が衰えてきているということもあるのですが、問題はそこではないでしょう。むしろ、個人の記憶力が頼りになってしまうというのはおかしいことです。しかし、それが現実だということです。 仕事ではどうしてもこの現実から脱却できないということがあります。正直なところ、モダンな開発スタイルを取り入れている現場の雰囲気は分かりません。私が長いこと携わっている現場がそうではないからです。優先
Build a CQRS event store with Amazon DynamoDB | Amazon Web Services
AWS Database Blog Build a CQRS event store with Amazon DynamoDB The command query responsibility segregation (CQRS) pattern, derived from the principle of command-query separation, has been popularized by the domain-driven design community. CQRS architectures that use event sourcing save generated events in an append-only log called an event store. By using event sourcing, you can, among other ben
PHPアプリケーションでEvent Sourcing、CQRSを実践する場合の ミドルウェアとの組み合わせ、基本的な考え方 実例を交えた資料です
注意 このページにアクセスするには、承認が必要です。 サインインまたはディレクトリの変更を試すことができます。 このページにアクセスするには、承認が必要です。 ディレクトリの変更を試すことができます。 一般的なアプリケーション向けの CQRS Dino Esposito ドメイン駆動設計 (DDD) は約 10 年前に登場し、ソフトウェアの開発者やアーキテクトに影響を与えています。具体的なメリットやデメリットはともかく、DDD は、オブジェクト指向パラダイムが初めて唱えられた頃、開発者の誰もが夢見たことを具体化します。つまり、包括的なオブジェクト モデルを中心にアプリケーションを構築して、すべての関係者の要件や懸案事項に対処するという夢です。 その後の 10 年、多くの開発者が DDD のガイドラインに従うプロジェクトに取り組んできました。成功したプロジェクトもあれば、失敗したプロジェクト
2018-02-28 wed. 第 3 回 Google Cloud INSIDE Games & Apps Fringe81株式会社 豊島 正規 氏の登壇スライドです。
CQRSに対する批判的見解
Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
超久しぶりのブログ…。 Octopressに疲れたのではてなブログに戻ってきました(Octopressの過去の記事ははてなブログにインポート済です)。ついでプロに移行。 さて、海外のDDDコミュニティではCQRS+Event Sourcing(以下, ES)が人気なのですが、ようやく日本でも話題になることが多くなったので今回は教材となりそうな書籍を簡単に紹介したいと思います。 DDD といえば まず エリック・エヴァンスのドメイン駆動設計 (以下 DDD本) を読むべきですが、CQRSについては記載がないので 実践ドメイン駆動設計 を読みましょう。 実践ドメイン駆動設計 作者: ヴァーン・ヴァーノン出版社/メーカー: 翔泳社発売日: 2015/03/19メディア: Kindle版この商品を含むブログ (2件) を見る さらにDDD本には ES の基礎となる ドメインイベント の解説が含まれ
前提 私は「エリック・エヴァンスのドメイン駆動設計」を読んだのみで、「実践ドメイン入門」は未読(とても欲しい)の状態で書いています。 (「実践ドメイン入門」にはもっと深い洞察が書いてあるのだと思います…) また「エリック・エヴァンスのドメイン駆動設計」と共に、参考リンク先をまず読んだことがある前提で書いている部分がありますのでご注意下さい。今後もっと良いアイデアが浮かんだり、実際に実装するにあたって浮かび上がった課題があれば随時追記・記事にできればいいなと思います。 参考 CQRS Documents by Greg Young Greg Young流CQRS - Mark Nijhof CQRS+ES DDDから更にData Flowの概念を取り込んだarchitecture。 コマンドクエリ分離原則(CQS/Command Query Separation)に基づく。 CQRSは Co
CQRS+ES(再)入門
AWS データベースブログの記事 「Amazon DynamoDBによる CQRSイベントストアの構築」 を勝手に読み解く
どすこい！ 昨年ぶりです！最近よくお相撲さんを見る@sitotkfmです！ またエンジニアブログを書かせて頂くことになりました！ 今回のトピックですが、最初は前回同様ストリーミングアルゴリズムでも発表しようかと思ったんですが、まああんまり受けが良くなかったので今回はパスで。。。(同期に「お前Advent Calender書いてたのかよ」と言われました。。。) それとあの後業務で本当にSparkをつかうことになりまして、まあ、えっと、本当に大変ですね。。。 さて今回のエンジニアブログではCQRSについて説明したいと思います。 CQRSが何故必要なのか まずドメイン駆動設計(Domain-Driven Degien)という、ビジネスの概念の抽象化であるドメインの要求を最優先として設計を行うソフトウェアの設計思想があります。 ここではドメイン駆動設計について説明しだすと主題から外れかねないのと私
)
CQRS Journey
July 2012 Exploring CQRS and Event Sourcing The project is focused on building highly scalable, highly available and maintainable applications with the Command & Query Responsibility Segregation and the Event Sourcing patterns. The project was positioned as a learning journey. This guidance is designed to help you get started with the CQRS pattern and event sourcing. It is not intended to be the d
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CQRS実践入門 [ドメイン駆動設計] - little hands' lab
DDDで設計するならCQRSの利用を検討すべき - Qiita
CQRSとイベントソーシングの使用法、または「CRUDに何か問題でも？」 | POSTD
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
なぜイベント駆動が必要なのか - CQRS/ESで解く複雑系システムの課題 -
Firestore で CQRS やってみた
(旧版)DDD × CQRS 更新系と参照系で異なるORMを併用して上手くいった話
ざっくりCQRS/Event Sourcingを解説する
そろそろイベントソーシング・CQRSを使ってみてもいい頃なんじゃない？
ZOZOSUITからZOZOMATへ - CQRSによる解決アプローチ - ZOZO TECH BLOG
CQRSはなぜEvent Sourcingになってしまうのか - かとじゅんの技術日誌
What the Flux? (On Flux, DDD, and CQRS)
マイクロサービスで DDD と CQRS パターンを使ってビジネスの複雑さに取り組む
CQRS+ESをAkka Persistenceを使って実装してみる。
CQRS/ESによって集約の境界定義を見直す - かとじゅんの技術日誌
CQRS パターン - Azure Architecture Center
RailsでCQRS/ESをやってみたきづき
タスクベースUIとCQRS - Qiita
CQSとCQRSの違いはメソッドの分離かモデルの分離かという観点 - Qiita
忙しいひとのためのCQRS/quickly-cqrs - Speaker Deck
CQRSの小さな演習(1) 現実の問題 - 考える場所
Event Sourcing,CQRS For PHP Application
Cutting Edge - 一般的なアプリケーション向けの CQRS
Ladder of cqrs+es
CQRS+Event Sourcingを学ぶための教材 - かとじゅんの技術日誌
CQRS+ESについて細かい実装や考察をまとめてみた - edy blog
『データ解析のシステムからCQRSについて学ぼう』