DDD Community JPのほうでCQRS/Event Sourcingについて少し盛り上がったので、どういう議論をしたかまとめるのと同時に補足も追加しました。ちなみに、Event Sourcingが主題ですが、CQRSも前提として関係します。その想定で読んでいただければと。 発端はこのツイート。 これはEvent Sourcingじゃないと無理ですね。状態に基づく限り、ストリーム処理は難しいです https://t.co/prB16GJC5q— かとじゅん (@j5ik2o) 2020年9月14日 僕が引用したツイートは松岡さんの質問箱に対するリアクションです。その質問箱に寄せられた質問は以下。 ストリームを開いてから閉じるまでのデータが変化する毎にUIで表示したい場合、DDDではどのように設計したら良いでしょうか？ DDDのリポジトリは1つのリクエストに対して1つのリクエストを返

AWS データベースブログの記事 「Amazon DynamoDBによる CQRSイベントストアの構築」 を勝手に読み解く

過去に僕が失敗した代表例から今ならどう設計するか、という観点でお話します。中心になるトピックは以下です - 軽量DDDの功罪 - ドメインモデル貧血症対策 - 集約の境界定義の善し悪し

この記事について 先日 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

AWS データベースブログの記事 「Amazon DynamoDBによる CQRSイベントストアの構築」 を勝手に読み解く

AWS データベースブログの記事 「Amazon DynamoDBによる CQRSイベントストアの構築」 を勝手に読み解く

より詳細な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 Summit 2017 Tokyo, Dev Dayで登壇した際の資料です。

9. copyright Fringe81 Co.,Ltd. It is not possible to create an optimal solution for searching,reporting,and processing transactions utilizing a single model. -CQRS documents by Greg Young-

前提 私は「エリック・エヴァンスのドメイン駆動設計」を読んだのみで、「実践ドメイン入門」は未読(とても欲しい)の状態で書いています。 (「実践ドメイン入門」にはもっと深い洞察が書いてあるのだと思います…) また「エリック・エヴァンスのドメイン駆動設計」と共に、参考リンク先をまず読んだことがある前提で書いている部分がありますのでご注意下さい。今後もっと良いアイデアが浮かんだり、実際に実装するにあたって浮かび上がった課題があれば随時追記・記事にできればいいなと思います。 参考 CQRS Documents by Greg Young Greg Young流CQRS - Mark Nijhof CQRS+ES DDDから更にData Flowの概念を取り込んだarchitecture。 コマンドクエリ分離原則(CQS/Command Query Separation)に基づく。 CQRSは Co

CQRSとイベントソーシングのざっくりとした紹介とAxonでの実装について CQRS（Command Query Responsibility Segregation：コマンドクエリ責務分離）とイベントソーシング 一般的なCRUDアーキテクチャとの比較 典型的なCRUDアーキテクチャでは以下のような形でシステムとの対話します。 データソースから取得した情報をモデルに反映し、それをもとにUIを表示 ユーザーがUIを通して情報を変更 変更をモデルに反映 モデルがバリデーションや間接的なロジックを実行 モデルの変更をデータソースに反映 このアーキテクチャはシンプルでり汎用性も高く、広く一般的に採用されています。 しかし、このアーキテクチャではDTOの送受信によるデータ中心の対話になるためドメインモデルの振る舞いが上手く表現できません。 CQRSとイベントソーシング CQRSとイベントソーシングを

書き込みと読み込みのどちらに力を入れているかは、ストレージエンジンによって異なります。たとえば昔ながらのリレーショナルデータベースは、外部キーなどの制約を使ってデータの整合性をうまく制御できるようになっています。一方でNoSQLデータベースは、スループットとスケーラビリティを確保するために、そういった組み込みのガードレールをはずしてしまいました。データ層においても、どちらか一方に特化した最適化をすることがあります。たとえば、あらかじめ計算済みの値を保持しておけば、「一日あたりのサイト訪問者数」などの読み込み操作を効率よく行えるでしょう。ストレージソリューションのメーカーはどこも、「うちのプロダクトならあらゆるニーズを満たせます」などと自社製品の機能を自慢します。しかし実は、昔ながらのCRUDモデルに沿ってストレージエンジンを選んでデータ層を設計した時点で、さまざまな関心事の間で何らかの妥協

lightbend社(旧 typesafe社) から先日 lagom というフレームワークがリリースされました。 DDD, CQRS, ES などに興味があったのでちょっと調べてみることにしました。 長くてまとまりがないですが、調査したことをメモとしてまとめてみます。 lagom とは lagom は Java によるマイクロサービス指向のフレームワークです。 以下が特徴のようです。 DDDの境界付けられたコンテキストによってサービスを分割し、それぞれのサービスは akkaの各プロダクトによって作られた実行環境で互いに(クラスタ構成であっても)連携する。 各サービスの実装はCQRS(コマンドクエリ責務分離)とES(イベントソーシング)の非同期呼び出しが基本となっていて、永続装置として cassandra がデフォルトになっている。 開発環境でのホットリロード(ソース変更の反映)、docke

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が最近リリースされ、重要な変...

InfoQ Software Architects' Newsletter A monthly overview of things you need to know as an architect or aspiring architect. View an example

DDD+CQRS+Event SourcingとAkkaでの実装ヒントを解説。