この記事では、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/fe5018ad772252621db406116ce62131478fb6b1/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20191202%2F20191202061944.png)
PFN Internship 2023 / Hagai Masaya: Towards Neural Network Potential for Excited states
PHPではじめるCQRSっぽいやつ
PHPerKaigi2021のアンカンファレンスで使ったものです。 PHPカンファレンス仙台2019の再演です。
AWS データベースブログの記事 「Amazon DynamoDBによる CQRSイベントストアの構築」 を勝手に読み解く
はじめに こんにちは、計測プラットフォーム部バックエンドチーム、テックリードの児島（@cozima0210）です。この記事では、ZOZOSUITとZOZOMATの違いにより生じたバックエンド開発における課題と、その解決のためにCQRSアーキテクチャを採用した経緯、そしてその実践について紹介します。 ZOZOSUITとは ZOZOSUITは、2017年に発表した全身の計測を目的としたツールです。現在も計測機能は提供されていますが、新規の販売は終了しています。現在、ZOZOSUITの計測データは、マルチサイズ商品の開発に活かされています。 ZOZOMATとは ZOZOMATは、2019年に発表した足の計測を目的としたツールです。足の計測データから、足型診断や推奨サイズの提案に活用されています。今年の2月にリリースし、ZOZOSUITに続く計測技術として、とても注目をいただきました。 計測プラッ
CQRSはなぜEvent Sourcingになってしまうのか、まとめてみたいと思います。 なぜまとめるか、それはCQRSにとってEvent Sourcingはオプションだと誤解されている方が多いからです。この記事を書いてる本人も最初はそう思っていましたが、実際に開発・運用を経験してみるとCQRSにとってEvent Sourcingはほぼ必須で、認識を改めるべきだと気づきました。なので、原義に基づいたうえで、Event SourcingではないCQRSがなぜよくない設計になるのか解説します。 その前に松岡さんの記事について。 CQRSの領域ではモデルを完全に分ける 松岡さんの記事には”CQRSはモデルを完全に分ける必要はない”と書かれていますが、知識がないと誤解しがちですが文字のまま意味を取るといけません。こちらの言及は、システムのうち、モデルをC/Qに分割するCQRS領域とモデルを分割しな
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-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 ただ、本稿はこのスライドの「内容」とは全く関係ありません。 本稿で取り上げたいのはこのタイトルに登場している CQSという単語についてです。 このスライドをきっかけにCQSとCQRSの違いについて自分なりに思考の整理を記載したいと思います。 CQS ? CQRS ? きっかけは twitter にて @j5
peing.net メッセージングシステムのお題のようです。面白そうなのでちょっと考えてみよう。 問題提起 集約候補が以下の3つ。 ユーザー 企業 スレッド メッセージ スレッド集約はメッセージを複数保持するようです。 1000件のメッセージを保持するスレッド集約を更新した際、1000件のアップデートが行われる スレッド集約内部で更新された属性を把握していない場合は、リポジトリでは全メッセージ分の更新となる。これを避けるための仕組みはどう実装するのか？ ということが指摘されている。まぁわかります。これはCQRS/ESなら解決できるよと言ってみる 問題の分析 で、僕ならどう考えて実装に落とすかつらつらまとめてみよう。CQRS/ES前提です。Akkaの成分は少なめでScalaの擬似コードで解説します。コードはコンパイルしてないので…おかしなところあるかも。 問題はスレッド集約がメッセージの集合
この記事は 弁護士ドットコム Advent Calendar 2020 19日目の記事です。12月19日の午前2時を過ぎて苛立ちがドアを叩くころです。 今年は上野学さんの単著『オブジェクト指向UIデザイン 使いやすいソフトウェアの原理』が発売され、OOUIという言葉が盛り上がっていますね。昨日のアドベントカレンダーの記事を書いた @shirauix さんともOOUIの話で盛り上がり、彼が主催で社内読書会も行われました。 さて、世間的にも社内的にもOOUIが盛り上がって読書会も開催されるなか、わたしは社内でひっそりと「タスクベースUI」の勉強会をやったのでした。 タスクベースUI？ 「タスクベースUI」という言葉は、先程の上野さんが盛んに言及することで最近有名になった言葉な気がします。 『オブジェクト指向UIデザイン』から引用します。 GUIのようにオブジェクトを起点として設計された操作モデ
アンケート作成システムのサーバサイドを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.
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 Streaming + CQRSをざっくり理解してみよう(Laravel) - ytake blog
これはさりげなく スターフェスティバル Advent Calendar 2020の20日目です。 PHPカンファレンス2020 2019年は登壇などを控えて一休みの期間としていたので一年振りくらいの と登壇となりました。 発表の内容としてはここ3、4年注力しているデータ処理まわりから、 PHPにおけるWebアプリケーションなどでも活用することができる題材を取り上げてお話させていただきました。 要するに事業に関わっている開発は年々要件も複雑になっていき、 問題解決するためにはいろんな手法があるけど、きちんと分析して 開発しやすいよう、フレームワークにべったり依存してつくるのではなく、 数年先を見越してつくったり、改善する方法の一つにCQRSもありますよ、という話です。 お話したように、全てのアプリケーションでペイできるものではありませんし、 ある程度大きな規模だったりある程度複雑な機能だった
ChatworkではリアクティブシステムとCQRS/ESを反映した次期アーキテクチャを構想しています。まだ構想段階ではありますが、なぜそれらを採用するのかメリット・デメリットも含めてご説明します。
株式会社ビープラウドが主催するIT勉強会「BPStudy」。#151となる今回は、設計の代表格であるオブジェクト指向、モデリング、そして設計にフォーカスをあて、LT大会を開催しました。Chatwork株式会社でテックリードとして活躍する加藤潤一氏は、「CQRS（コマンドとクエリの分離）」について語りました。 講演資料はこちら コマンドとクエリを分けるCQRSとは 加藤潤一氏：今日は「CQRSはEvent Sourcingなしで実現できるのか？」という話をします。よろしくお願いします。自己紹介は割愛させてください。 Event Sourcingの事例は、Chatworkでも2016年にNTTデータさんと共同開発したプロジェクトです。AWSのDev Day（AWS Dev Day Tokyo 2017）で話したので、スライドもあります。あとはApache Kafkaを使っているんですけど、NT
３週間で出来たEvent SourcingでCQRSなアーキテクチャ上でのHBaseのupgrade - Chatwork Creator's Note
プロジェクトのリーダーである、cw-sakamotoがこの超重要プロジェクトを終え、軽い燃え尽き症候群になっているので、代わりにcw-tomitaが代筆しております。 マラソンガチ勢(ベストタイム３時間１７分)であるcw-sakamotoによって、Carbon X(50マイルでの世界記録を出したランナーが履いていたランニングシューズの名前)と名付けられた、このHBase upgradeプロジェクト、 dogsorcaravan.com その名に恥じない、プロジェクト開始から終了まで３週間という短納期で完遂することができました。今回はこのプロジェクトに関して書きました。 tl;dr Event SourcingでCQRSなシステムの上で動いてるHBaseのversion upをblue-green形式で実施した。 計画から実行まで３週間程度で完了するというスピード感で、大きな事故もなく凄く上
CQRS/Event SourcingといえばAkka/Scalaがオススメと言い続けてきたけど、言語やフレームワーク非依存というか、そういう縛りが緩い方法を考えた(実際に検証したわけではないですが、実装できるつもりで書いてます)ので、以下にまとめます。 前提 クラウド環境はAWS。コマンド側DBをDynamoDB。DynamoDBにそれなりに詳しい人向けに基礎的な部分の解説も省いてます。クエリ側DBは要件に応じて選択してください。とりあえずAuroraのつもりで書きます。 コマンド側で発生したイベントをクエリ側に伝搬させるために、DynamoDB Streamsを利用します。クエリ側のRead APIはRead DBを読むだけなので解説は省きます。 ドメインはショッピングカートです。 アプリケーションは伝統的なステートレスウェブアプリケーションを想定します。アプリケーションの最新状態(S
Kaigi on Rails 2023 (https://kaigionrails.org/2023/talks/krpk1900/) で発表した内容です。
前回の記事で、リレーショナルデータベースの役割として、以下の3つを挙げ、ドメイン駆動設計においては最後のものにあまり重きが置かれていないことを指摘した。 集合演算によるリレーションの導出（検索） ディスクへの書き込みによる永続化（蓄積） 各種制約によるデータの整合性の確保 ky-yk-d.hatenablog.com 本記事では、リレーショナルデータベースの特性を改めて検討し、その特性からの帰結としてCQRSとSQLQLを位置付けてみたい。 リレーショナルモデルにおける整合性の確保 整合性の確保をリレーショナルデータベースが担うという発想は、決して新奇なものではない。リレーショナルモデルの父であるコッドの1970年の論文「A Relational Model of Data for Large Data Banks」*1でも、データの整合性（consistency）というテーマが大きく取り
Axon Framework で簡単にEventSourcing+CQRSなアプリケーションを作る - エムスリーテックブログ
この記事はエムスリーAdvent Calendar 2023の13日目の記事です。 こんにちは、製薬企業向けプラットフォームチームエンジニアの桑原です。 前回のJJUG CCC の登壇についてのブログで Axon Framework について軽く触れました。今回はAxon Frameworkがどのようなもので、どういった使い方をするかを紹介したいと思います。 背景：CommandとQueryに最適なモデルが異なる CommandとEvent追記型との相性は良かった QueryがEvent追記型との相性は良くなかった 苦肉の解決策 Axon Framework ざっくりアーキテクチャ Command EventからReadModelへのマッピング Query まとめ 参考記事 We are Hiring! 背景：CommandとQueryに最適なモデルが異なる 上述のリンクで紹介したメッセー
Chatwork に所属するエンジニアや外部ゲストなど、多分野のエキスパートたちの登壇を通して、エンジニア組織で取り組んでいる試みなどの知見を提供する「Chatwork Dev Day 」。ここで開発部テックリードの加藤氏が登壇。まずは、新アーキテクチャの設計思想でCQRS、Event Sourcingを採用した背景を紹介します。 セッションのアジェンダ 加藤潤一氏（以下、加藤）：それでは、私のセッションを始めたいと思います。アジェンダはこのようになっています。最初はリアクティブシステムと、それに関連してCQRS（Command Query Responsibility Segregation）とEvent Sourcingについて話したいと思います。アーキテクチャの刷新を計画していて、その新アーキテクチャの設計思想の中にこの2つの概念が関わってくるので、最初に話したいと思います。 CQR
Chatwork に所属するエンジニアや外部ゲストなど、多分野のエキスパートたちの登壇を通して、エンジニア組織で取り組んでいる試みなどの知見を提供する「Chatwork Dev Day 」。ここで開発部テックリードの加藤氏が登壇。続いて、Event Sourcingと、新アーキテクチャの具体的な設計内容を紹介します。前回の記事はこちらから。 なぜEvent Sourcingなのか 加藤潤一氏（以下、加藤）：「なぜEvent Sourcingなのか」という話で、Event Sourcingの場合はどうなっているかというと、CRUDのステートソーシングは、最新のエンティティを上書きする考え方です。Event Sourcingは、そのとき発生した変更を追記していく考え方になります。 「状態はどういうふうに作るの？」という話ですが、イベントから状態を導出する考え方です。関数にイベントをapplyし
Introduction 一般的になってきたCQRSとEvent Sourcing。 これらのアーキテクチャは、RDBMSやNoSQLデータベースをデータストアとして持っている、 昔ながらのCRUDデータモデルの代案として近年採用が進んでいます。 本稿ではCQRS・EventSourcingの簡単な説明と、 それらを用いたサンプルをTypeScriptで実装してみます。 What is CQRS? CRUDと違い、CQRS(Command and Query Responsibility Segregation)は データの読み込みと書き込みは本来違うものである、という前提に基づく考え方で、 2010年にGreg yang氏が考案していたものです。 あらゆるメソッドは、アクションを実行するコマンドか、 呼び出し元にデータを返すクエリかのいずれかであって、両方を行ってはならない。 これは、質
世の中にはクラウドを採用していても、スケーラビリティのないサービスを開発・運用しているエンジニアは少なくないと思います。過去の私もその一人でした。CQRS/Event Sourcingはその解の一つです。私自身も2016年にCQRS/ESに出会って以来、AWS上でその根本的な課題に取り組んで来ました。その経験を生かしてAWSでの実現方法について解説します。
この記事の更新版です。 僕がCQRSに入門したの2016年でした。すでに海外のDDDコミュニティではCQRS/Event Sourcing(以下, ES)に関する議論は盛んにされていました。 2020年になってようやく日本でも話題になることが多くなった印象なので、教材となりそうな書籍などの情報を簡単に紹介します。 前提となる教材 前提としてはEvans本を読んでいるということにさせてください。 さらにDDD本には ES の基礎となる ドメインイベント の解説が含まれていません。そのドメインイベントの概要を掴みたければ、実践ドメイン駆動設計に記載があります。 基礎教材 考案者であるGregさんのドキュメントです。 CQRS Documents by Greg Young 和訳版はこちら。CQRS Documents by Greg Young 和訳版 概念を把握するならこれが以外にないです。
最初に GraphQLは参照系のQueryと更新系のMutationの２種類が区別して定義されています。 このように参照系と更新系のinterfaceを分けているため、GraphQLはCommand and Query Responsibility Segregation(CQRS)だと説明されることがあります。 確かにその通りなのですが、なぜCQRSのアーキテクチャなのか、具体的にQueryとMutationを定義する際にどういったことを意識するべきなのかということはあまり説明されていないように思います。 この記事ではCQRSがどういったことを意図しているのか、それを元にどのようにGraphQLでスキーマを設計するべきなのか説明します。 REST APIの問題点とCQRS RESTはURLで表現されるデータに対してCRUD(Post, Get, Put, Delete)のアクションを定義
Amazon Web Services ブログ Amazon DynamoDB を使った CQRS イベントストアの構築 コマンドクエリ責務分離（command query responsibility segregation, CQRS）パターンは、もともとコマンドクエリ分離の原則から導出されたもので、ドメイン駆動設計コミュニティの啓蒙によって広く知られるようになったものです。イベントソーシングを使用した CQRS アーキテクチャは、イベントストア と呼ばれる追加のみを許されたログに、作成されたイベントを保存します。イベントソーシングを利用することによっていろいろなメリットがありますが、中でも次のようなことができるようになります： データベースとメッセージブローカーを跨ぐような複雑な分散トランザクション（いわゆる 二相コミットプロトコルによるトランザクション）を用いなくてもデータベースの
This book explains and illustrates how to implement Domain-Driven Design, Command Query Responsibility Segregation and Event Sourcing. The goal is to build software that is behavior-rich, event-based, problem-centric, reactive, scalable and well-designed. Domain-Driven Design is a way to build software that focuses on the problem to solve and its associated knowledge areas. Command Query Responsib
CQRS 完全に理解した
はじめに CQRS を何となく理解するための記事です。 DDD の文脈から来ている概念ですが、この記事では DDD について深く触れません。DDD の知識がなくてもわかるように書いた（つもり）です。 CQRS ざっと理解 Command and Query Responsibility Segregation コマンドクエリ責務分離原則 Command(Write) と Query(Read) のモデルを分離するパターン Commands: Change the state of a system but do not return a value. Queries: Return a result and do not change the observable state of the system (are free of side effects). (引用) https://ma
Microservices with CQRS and Event Sourcing in TypeScript with NestJS
Recently, I published three articles, each on Domain-Driven Design (DDD), CQRS, and event sourcing. In each of these articles, I have made it clear that while these concepts and architectures are independent, they complement each other perfectly, especially in the context of microservices and APIs. However, I would like to go into this interaction more closely today. I created a simple open-source
AWS データベースブログの記事 「Amazon DynamoDBによる CQRSイベントストアの構築」 を勝手に読み解く
はじめに x と y と z を JOIN して COUNT した値を画面に表示したいなど、画面が要請する値を DB からごにょごにょと集計して API で返したくなることがあります。1 そんなとき、DB のモデルをドメインモデルにマッピングし、ドメインモデルを API のインターフェースにマッピングして返すような実装をしていると、以下のような問題にぶつかります。 集計後の値を取得したいだけなのに、大量のオブジェクトをアプリケーションのメモリ上にロードすることになる ちょっと取得する値を追加・変更するだけでもドメインモデルに影響が出てしまう 使っている O / R マッパ によっては N + 1 問題が発生しやすい ドメインモデルを集約単位で扱っていると、アプリケーション上で JOIN の処理を実装することになる この記事では、簡易的な CQRS で上記の問題を解決してみます。 CQRS
CQRS Software Architecture Pattern: The Good, the Bad, and the Ugly
Photo by Jukan Tateisi on UnsplashThe Command and Query Responsibility Segregation (CQRS) it’s an architectural pattern where the main focus is to separate the way of reading and writing data. This pattern uses two separate models: Queries — Which are responsible for reading dataCommands — Which are responsible for update dataIn a Nutshell - The Command and Query Responsibility Segregation (CQRS)
掲題についての議論です。 僕の結論はこちら。"モジュール分割せずにモデルを分割するだけ"はCQRSと呼んでいけないのでは？まず原義からちゃんと把握しようというお話。 CQRSするにはC/Qは独立しないとダメなので、それをどう連携させるかすごい難しい課題。ESなしでは独立させて統合するのはほぼ難しいと思います https://t.co/Ta0CYujHJx— かとじゅん (@j5ik2o) 2020年9月17日 sipadan2003.blogspot.com Gregさんの原義によると Origins 起源 Command and Query Responsibility Segregation uses the same definition of Commands and Queries that Meyer used and maintains the viewpoint that
CQRSとCQSの違い
こんにちは。株式会社プラハCEOの松原です 先日プラハチャレンジで「CQSとCQRSって何が違うんだろうね？」と話し合ったので内容をまとめてみます。 結論:CQRSとCQSの違い CQSはオブジェクト単位でメソッドの責務を更新と取得に応じて明確に分離すること CQRSはそれをアーキテクチャレベルに適用したもの。ただ、データソースの分離を行うか〜など分離レベルに関する定義は様々存在した CQSの定義 我らがMartin Fowler氏によればCQSという用語自体が登場したのはBertrand Meyer氏の書籍で、 The fundamental idea is that we should divide an object's methods into two sharply separated categories: と記載の通り、「オブジェクトのメソッド」を2つのカテゴリ（クエリとコマ
CQRS/Event Sourcingは、非機能要件の側面で注目されがちですが、本来はDDDのための設計パターンの一つです。 今回は言語非依存に実装する方法を共有しつつ、一緒に手を動かして理解できるようするハンズオン用セッションです。 想定条件 コードを書きたい人はPCをご持参ください 事前にソースコードとセットアップ手順を共有します。あかじめセットアップし動作確認可能な状態でご参加ください。 対象言語でFizzBuzz以上のプログラムが書ける開発者向け ※難しいコードは書きません。手本のコードは共有します。 参加者はプログラミング言語としてGoもしくはRustの好きな方を選択できます ※このセッションを受けると他の言語でも実装できるようになります 想定データベースとしてはコマンド側がDynamoDB、クエリ側はMySQL(RDS) 実装ではREST API,GraphQLを使うのでその経
CQRS なレコメンドシステムをGCP で構築した話 - スタディサプリ Product Team Blog
こんにちは、データエンジニアの @masaki925 です。 今年の春リニューアルされたスタディサプリの中学講座にて、レコメンドシステムを新規構築しました。 そのアーキテクチャが、当初意図していなかったものの、結果的にはCQRS (Command Query Responsibility Segregation) パターンと呼べるものになっていました。 本記事では、CQRS の特徴に則って当該アーキテクチャを紹介しつつ、今後に向けて考察します。 CQRS パターン + イベントソーシング なぜCQRS + イベントソーシングか 1. 分析用の学習ログと、レコメンドシステム用の学習ログは分けたい 2. 直前の学習状況をリアルタイムに反映したレコメンドをしたい 3. レコメンドロジックはルールベースで開始し、ログが溜まったのちに機械学習(ML) ベースに移行したい 4. 学習ログはスナップショ
Chatwork に所属するエンジニアや外部ゲストなど、多分野のエキスパートたちの登壇を通して、エンジニア組織で取り組んでいる試みなどの知見を提供する「Chatwork Dev Day 」。ここで開発部テックリードの加藤氏が登壇。続いて、CQRSについて紹介します。前回の記事はこちらから。 なぜCQRSなのか 加藤潤一氏（以下、加藤）：「なぜCQRSなのか」という話がありますが、自律性を表明することがあって。「独立して行動し、協調的に相互作用するコンポーネントを設計する」という考え方があります。どういうことかというと、自律性って、結局ほかのサービスと独立して機能しないと意味がありません。 マイクロサービスの動作保証は、連携しているほかのサービスと直接関係がないように、常に自分のサービスの行動を保証するだけという原則があります。ドメイン境界で割っていくと、それぞれ独立したコンテキストでシステ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CQRS実践入門 [ドメイン駆動設計] - little hands' lab
Firestore で CQRS やってみた
ざっくりCQRS/Event Sourcingを解説する
ZOZOSUITからZOZOMATへ - CQRSによる解決アプローチ - ZOZO TECH BLOG
CQRSはなぜEvent Sourcingになってしまうのか - かとじゅんの技術日誌
CQSとCQRSの違いはメソッドの分離かモデルの分離かという観点 - Qiita
CQRS/ESによって集約の境界定義を見直す - かとじゅんの技術日誌
タスクベースUIとCQRS - Qiita
忙しいひとのためのCQRS/quickly-cqrs - Speaker Deck
リアクティブシステムとCQRS/ESで実現する Chatwork新アーキテクチャについて
Chatworkのテックリードが語る、CQRSを上手に使うため方法
CQRS & Event Sourcing - モダンアーキテクチャにおける役割と実装
DynamoDBを使ったCQRS/Event Sourcingシステムの構築方法(言語・F/W非依存)
Fat Modelを解消するためのCQRSアーキテクチャ
リレーショナルモデルにおける制約とCQRS・SQLQL - こまぶろ
“止まらないシステム”ではなく“回復する能力”に価値がある リアクティブシステムを実現するためのCQRSとEvent Sourcing
「CQRSをやる」は「Event Sourcingをやる」とほぼ同義 リアクティブシステムとCQRSを反映した新アーキテクチャの設計思想
TypeScriptでCQRS & Event Sourcing | DevelopersIO
AWSでCQRS Event Sourcing するにはどうすればいいのか
CQRS/Event Sourcingを学ぶための教材(2020年版)
CQRSの観点から考えるGraphQLのスキーマ設計
Amazon DynamoDB を使った CQRS イベントストアの構築 | Amazon Web Services
Implementing DDD, CQRS and Event Sourcing
CQRSはEvent Sourcingなしで実現できるのか？
簡易 CQRS で「画面に ~~ も表示したいんだけど」に強い API を実装 - Qiita
CQRSはモデルだけでなくモジュールも分割する - かとじゅんの技術日誌
CQRS/Event Sourcingシステム実装入門
“自律性”は独立で機能しないと意味がない コマンド・クエリの要件から考えるCQRSの利点と欠点