【第1回・前編】 エンジニア和田卓人の今を形作る技術 | GeeklyMedia(ギークリーメディア) | Geekly（ギークリー） IT・Web・ゲーム業界専門の人材紹介会社
『テスト駆動開発』や『SQLアンチパターン』をはじめとする技術書の翻訳者、さまざまなIT企業をわたり歩く技術顧問、さらに最近ではエンジニアリング文化を伝える講演者としても活躍されている和田卓人さん(https://twitter.com/t_wada)。 そのソフトウェアエンジニアとしての素顔を株式会社一休CTOの伊藤直也さん(https://twitter.com/naoya_ito)が聞き出す対談の前編では、一線を画すエンジニアであり続けるために自らのプロジェクトで意識的にコードを書いているという和田さんの姿勢に始まり、ベテランとして「技術のらせん」を読み解くケーススタディとしてDDD（Domain-Driven Design）を題材に話を伺います。 ・伊藤 直也さん / 株式会社 一休 執行役員 CTO 新卒入社したニフティ株式会社でブログサービス「ココログ」を立ち上げ、CTOを務め
フロントエンドエンジニアが「自分はJSON色付け係」と自虐する理由を考察した - パンダのプログラミングブログ
パンダとおくだが、Web業界の当たり前を「これって本当にそうだっけ？」と問い直すラジオを配信しています 「JSON色付け係」という自虐 フロントエンドエンジニアの間では、「私の仕事は JSON に色を付けることです」という有名な自虐ネタがある。 おそらく初出は以下のツイートなのだろう（*1）。ただ、出典はあまり詳しく調べていない。 初めてこの言葉を見た時、面白い言い回しだなと思った。確かにフロントエンドの仕事にそういう側面はある。 実際、コンテンツの表示がメインのページで作業すると上記のような気持ちになる。この場合、フロントでやることといえばせいぜい日付の表示形式を適切にフォーマットするくらいだ。結局バックエンドからデータが返ってこないとフロントだけでは何もできないと思うこともある。 もちろん、フロントだけで簡潔する手書き風グラフ作成ツール excalidraw のようなものは別だし、フロ
公開日 2024/05/27更新日 2024/12/02注目のITサービスを支えるアーキテクチャ特集 技術選定のポイントと今後の展望 現代のITサービスは、ユーザーに高品質で安定した体験を提供するために、より効率的で柔軟な技術選定が不可欠です。 本特集では、注目企業のシステムアーキテクチャ設計に携わるエンジニアの方々より、それぞれの技術選定における工夫と、未来を見据えた展望についてご寄稿いただいています。 各企業がどのように課題を乗り越え、開発生産性や品質を向上させるためにどのようなアプローチを採用しているのか ー この記事を通じて、実際の現場で活用される最先端の技術や戦略を学び、皆さんのプロジェクトに役立つ洞察を得ていただければ幸いです。 ※ご紹介はサービス名のアルファベット順となっております airCloset - 株式会社エアークローゼット会員限定コンテンツ無料登録してアーキテクチャ
私のよく使うソフトウェアアーキテクチャの雛型
サンプルプロジェクト 構成 イベント駆動と CQRS を意識した、レイヤードアーキテクチャをベースとしたヘキサゴナルアーキテクチャになります。 各層について レイヤードアーキテクチャをベースに、以下の4層に分けています。 プレゼンテーション層: ソフトウェアの入出力を担当 アプリケーション層: ソフトウェアのユースケースを担当 ドメイン層: ドメイン知識を元にしたビジネスのルールや制約、プロセスを担当 インフラストラクチャー層: 技術的関心ごとの全般を担当 ディレクトリ構成 domain/ # ドメイン層 models/ ## ドメインモデルを格納 services/ ## ドメインサービスを格納 application/ # アプリケーション層 use-cases/ ## ユースケースインプットポートを格納 interactors/ ## コマンドにあたるユースケースの実装クラスを格納
このYouTubeライブはフロントエンドの最適化を専門にするmizchiさんがCloudflare Meet-up Tokyoで行った同タイトルのプレゼンを、RustやRDBの実装に詳しいkoba789さんを話し相手に語っていくというものだ。背景としては2人ともチーム開発の現場でのRailsが活発に利用されていた時期にウェブ開発を経験し、現在はNode.jsのサーバーサイドも実践している。 ライブは3時間半という長時間におよび、スライド外の周辺情報や持論や余談など多岐に渡るので、すでにこのプレゼンに触れた人でもさらに深掘りできるようなコンテンツになっている。 全体を大まかに1時間ごとの3パートに区切って視聴するとわかりやすい。前半はRailsからNext.jsに辿り着くまでのウェブ開発の変遷。ORMの話は主に後半戦で。最後の1時間はアフタートークになっている。 内容としてはRailsアプリ
アーキテクチャの進化はドメインイベントが起点になる - KAKEHASHI Tech Blog
こちらの記事はカケハシ Advent Calendar 2023 Part2の24日目の記事になります。 adventar.org はじめに 反復的な開発は、変更容易性の高いソフトウェアが不可欠です。ソフトウェア開発の経験がある方なら、デリバリ後の洞察や市場環境の変化から、新しい機能の追加やアーキテクチャの進化の必要性に直面したことが一度はあるでしょう。 私自身、要求分析手法やSOLID原則等の技法を取り入れ、変更容易性に対応する多くのプロジェクトに参加しました。しかし、どれだけ優れた手法や技法を持っていても、変更が難しい要求が出てくることは避けられません。その際、「過去の出来事」を正確に記録していれば、後から見返して問題解決が容易だったと感じることがよくあります。 ドメイン駆動設計（DDD）では、「過去に起こった出来事」を表現するドメインモデルを「ドメインイベント」と呼びます。変更容易性
Amazon Web Services ブログ サーバーレスマイクロサービスを構築するための設計アプローチの比較 AWS Lambda でワークロードを設計すると、コードレベルでもインフラレベルでも表現できるモジュール性のために、開発者に疑問が生じます。また、コードを実行するためにサーバーレスを使用するには、基盤となる機能コンポーネントからビジネスロジックを抽出するためのさらなる検討が必要です。この意図的な関心の分離により、堅牢なモジュール性が保証され、進化的なアーキテクチャへの道が開かれます。 この投稿は同期ワークロードに焦点を当てていますが、他のワークロードのタイプでも同様の考慮が当てはまります。API の境界を特定し、コンシューマと API について擦り合わせた後、その境界と関連するアーキテクチャを構成します。 Lambda 関数を使用して API を構成する最も一般的な 2 つの方
Kubernetesでセルフホストが簡単なNewSQLを求めて / Seeking a NewSQL Database That's Simple to Self-Host on Kubernetes
イベント駆動アーキテクチャ導入の手引きと共通の落とし穴 / Guide to Implementing Event-Driven Architecture and Common Pitfalls
イベント駆動アーキテクチャにおける落とし穴についてお話しています。 こちらは JJUG CCC 2024 Spring の講演用資料です。 Code: https://github.com/nrslib/pubsubdoc # URL YouTube: https://www.youtu…
こんにちは！sugitaniと申します。 これまで有名芸能人と通話ができる(かもしれない)ライブ配信アプリとか、オリジナルマンガの配信サービスとか、コメントが横に流れるライブ配信システムとかを作ってきました。(SUGARは今も作業してます) 最近ご縁がありましてUUUMの子会社で、簡単に有料フォロワー向けの投稿が行えるFOLLOW MEを主に開発していて、NFTでデジタルトレーディングカード(※)を売り買いすることができるHABETをIndieSquare社さんと協業で運営しているNUNW株式会社(5月にFOROから社名変更)に入社し半年くらい経っています。最近CTOに任命していただきました！ ※NFTについては思うことがある開発者の皆様が多いと思っていますが、自分がどう思っているかは後述します 少し前に「スタートアップがまともなわけ無いから入るな」というインタビュー記事を書いて頂いたんで
DDDを実践するための手引き（ドメインイベント編）
ドメインイベントを扱う実装は様々な流派があり、本記事ではなるべく一般的なものを取り上げたいと思っていますが、あくまで一例です。 実装例は Kotlin を使っていますが、他の言語でも同様の実装が可能です。 ドメインイベントとは イベントとは「過去に発生した出来事」であり、ドメインイベントは「ビジネスドメイン上で発生した重要な出来事を表すメッセージ」です。 （例: チケットが割り当てられた、注文がキャンセルされた） ドメインイベントはシステム内の状態の変化（=集約の状態の変化）を表現するものであり、通常は集約がドメインイベントの発生源となります。 用途 ドメインイベントは主に次のような目的で使用されます。 1. イベントの発生を起点に、別の処理をトリガーする ドメインイベントは、システムの異なる部分間を連携させるために使用されます。 ドメイン上の要件として「...したら...する」のようなフ
AWS×クラウドネイティブソフトウェア設計 / AWS x Cloud-Native Software Design
JAWS DAYS 2026 でクラウドネイティブなソフトウェア設計についてお話した際の資料です。 イベントドリブンアーキテクチャなどについて語っています。 TAKT： https://github.com/nrslib/takt ユーザーコミュニティ： https://discord.gg/…
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とメッセージングシステムへの二重書き込みを避けることで障害などのタイミングで顕在化する潜在
そろそろイベントソーシング・CQRSを使ってみてもいい頃なんじゃない？ いろんな面で準備が整ってきています... イベントソーシングの良さを伝えつつ、Xでイベントソーシングやドメイン駆動開発について話している方、また吉祥寺.pm36参加予定の方を対象にしたアンケート結果を発表します！ 1.…
CQRS設計パターンをモダナイズする
CQRSとは CQRS（Command Query Responsibility Segregation、コマンド・クエリ責務分離）は、ソフトウェアアーキテクチャパターンの一つで、つまりシステムのコマンド部分をクエリ部分から分離します。基本的な考え方は、データの書き込み操作（コマンド）と読み取り操作（クエリ）を異なるモデルで扱うことです。これにより、スケーラビリティ/パフォーマンス/セキュリティの観点で柔軟な設計が可能となり、クエリ要件に合わせて最適化が実現できます。 CQRSの基本構成としては、 コマンドモデル（書き込みモデル）：データの作成、更新、削除といった書き込み操作を担当します。このモデルは、データの整合性と一貫性を確保するために最適化されています。 クエリモデル（読み取りモデル）：データの読み取り操作を担当します。このモデルは、クエリのパフォーマンスを最大化するために最適化され
Domain Event
目次 概要 この記事の内容 対象読者 注意事項 前提知識 定義 用途 モデリング 不変性 独立性 汎用情報 個別の情報 Versioning 実装 前提 フレームワーク Domain Eventの処理 型定義 interface DomainEventEnvelope Enum Domain Eventの内部通知 staticなEvent Publisherを用意してAggregateがPublisherを呼び出す 実装例 AggregateのCommandの返り値としてDomain Eventを返す 実装例 Aggregateで保持してGetterで取り出す 実装例 永続化と外部通知 要件 永続化 外部通知 まとめ 参考文献 概要 この記事の内容 Domain Eventは非常にシンプルな概念かつ強力なモデリングパターンです。 モデリングにおいては直感的に扱うことが可能ですが、実装をする
AWS については利用していないのでよくわからない。あくまで Erlang/OTP で書かれたミドルウェアのリプレイス事例として感想を雑に書く。ちなみに、現地で発表を聞いている。 一般的な感想 自分のような AWS 素人が見てもわかりやすいシンプルなシステムになっていた HTTP/2 を利用した独自プロトコルでの双方向通信が気になる TCP/IP を利用した大量の常時接続は本当に大変だとおもう カーネルパラメーターチューニング！ 少ないリソースで、たくさんの接続を担う ゴールが素晴らしい デプロイの自動化を GitHub Actions でやってるのやっぱりいい 負荷試験にて1億台の接続を維持した状態で挙動が問題ないことを確認 最高 Graviton ベースの Fargate の活用 Go であれば arm64 向けバイナリがサクッと生成されるのは良い Erlang/OTP から Go へ
株式会社ジェイテックジャパン CTOの高丘 @tomohisaです。C#イベントソーシング・CQRSのフレームワーク、Sekibanを社内で開発しています。オープンソースで公開していますのでよろしければソースコードだけでもご覧ください。 はじめに 削除フラグを使うかどうかが最近ネットで話題になっています。t_wadaさんがおっしゃっているように、とりあえず削除フラグというのはアンチパターンで、ビジネスドメインでの意味を表現する形にするのが良いというのに同意です。 これらの削除フラグに関する議論を見て、「イベントソーシングではどう扱うのか」という質問をいただきました。 この記事では、イベントソーシングでの削除の考え方を紹介します。 前提：イベントソーシングはCQRSと組み合わせる イベントソーシングを行うときは、CQRS（コマンドクエリ責務分離） と組み合わせて使うことが前提となります。 C
はじめに こんにちは。基幹システム本部・リプレイス推進部・リプレイス推進ブロックの岡本です。 私たちのチームでは、ZOZOの基幹システムリプレイスの一環として、会計領域のシステムを新規構築しています。アーキテクチャにはCQRS（Command Query Responsibility Segregation）+ES（Event Sourcing）を採用しました（以降、CQRS+ESと略記します）。 本記事では、CQRS+ESを実務へ適用する中で直面した「小さな集約を保ちながら、大量の集約をまたいだ業務出力をどう実現するか」という課題と、その解決で得られた知見を紹介します。 会計システムでは、決済に関連する明細データを決済ID単位の小さな集約（Aggregate）として設計しています。一方で、消込結果を月次でまとめた帳票を出力するようなユースケースでは数万件規模の集約を横断する必要があり、集
イベント履歴式ドメインモデル（イベントソーシング）とは何か - ENECHANGE Developer Blog
はじめに システム開発部でバックエンドエンジニアをしている白坂です。 弊社では、『ドメイン駆動設計をはじめよう』の輪読会を行っています。 この記事では、第7章で扱われているイベント履歴式ドメインモデル（イベントソーシング）について自分の理解を整理します。 これからDDDを学ぶ方の参考になれば幸いです。 はじめに 多くのシステムは「現在の状態」を保存する しかし業務では「過程」が重要 「状態」ではなく「出来事」を保存する 状態保存とイベント履歴式ドメインモデルの違い 状態を保存する設計 イベント履歴式ドメインモデル 現在の状態はどう扱うのか なぜこの持ち方をするのか イベント履歴から目的別のモデルを作れる イベントストアとは イベントストアの特徴 メリット 過去の状態を再現できる 業務の流れを詳しく把握できる 履歴をそのまま監査に使える 同時更新の内容を見て判断できる デメリット 学習コスト
DDDにCQRSをどう組み込むか～バックエンドアーキテクチャ設計時の考え方 - TechDoctor開発者Blog
はじめに こんにちは。テックドクターでバックエンドエンジニアをしている筧と申します。 新規プロダクトのバックエンドで、DDD (Domain-Driven Design) と CQRS (Command Query Responsibility Segregation) を組み合わせたアーキテクチャを採用しました。 DDDの本や記事は、Eric Evans著『Domain-Driven Design』や『実践ドメイン駆動設計』など様々あります。CQRSについてもMartin Fowler氏のCQRSの解説記事などがあります。しかし、DDDにCQRSをどう組み込んでいったかという話はあまり見かけません。 この点について以前より情報収集や試行錯誤を重ねていましたが、今回のプロダクトでようやく納得のいく形で実装ができました。この記事ではそのポイントをご紹介します。特にCQRSを具体的に実装してい
What's in a price? How to price your products and services
株式会社ジェイテックジャパン CTOの高丘 @tomohisaです。C#イベントソーシング・CQRSのフレームワーク、Sekibanを社内で開発しています。 はじめに Xでこんな疑問を見かけました。 技術的には「現在のポイントに対して+20」みたいなコマンドも存在するしその場合はコマンドにも読み取りが伴ってきて、責務的境界と技術的境界ってズレないか 書き込みDBと読み取りDBをカッチリ分けている例が多くて、そこんとこみんな整合性どうしてんのって思って今でもわからない 「読み書きのDBを分けたら、古いデータを読んでしまうのでは？」という疑問は、CQRS/ESを学び始めたときに多くの方が感じるところだと思います。 この記事では、CQRS/ES（イベントソーシング）でどう整合性を守っているのかを解説します。
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
CQRS/Event SourcingといえばAkka/Scalaがオススメと言い続けてきたけど、言語やフレームワーク非依存というか、そういう縛りが緩い方法を考えた(実際に検証したわけではないですが、実装できるつもりで書いてます)ので、以下にまとめます。 前提 クラウド環境はAWS。コマンド側DBをDynamoDB。DynamoDBにそれなりに詳しい人向けに基礎的な部分の解説も省いてます。クエリ側DBは要件に応じて選択してください。とりあえずAuroraのつもりで書きます。 コマンド側で発生したイベントをクエリ側に伝搬させるために、DynamoDB Streamsを利用します。クエリ側のRead APIはRead DBを読むだけなので解説は省きます。 ドメインはショッピングカートです。 アプリケーションは伝統的なステートレスウェブアプリケーションを想定します。アプリケーションの最新状態(S
本記事は私の実装経験と考察をベースにしています。各セクションの根拠となる一次情報源は、該当箇所に参照リンクを記載しています。 DDDで設計されたプロジェクトにCQRSを導入しようとすると、さまざまな疑問が出てきます。「ユースケースとCommandの違いは何か」「QueryServiceはどの層に置くのか」「リポジトリはどうなるのか」といった点です。 この記事では、DDD × CQRSの導入時に誤解しやすいポイントを整理し、理想的なディレクトリ構成とコードサンプルをもとに解説します。 CQRSとは何か（1分でおさらい） Command Query Responsibility Segregation（コマンドクエリ責務分離） CQRSの核心は「情報を更新するモデルと、情報を読み取るモデルを分けられる」という考え方です。ただし、多くのシステムでCQRSは不必要なリスクと複雑性を加えることにも注
Chatwork に所属するエンジニアや外部ゲストなど、多分野のエキスパートたちの登壇を通して、エンジニア組織で取り組んでいる試みなどの知見を提供する「Chatwork Dev Day 」。ここで開発部テックリードの加藤氏が登壇。続いて、Event Sourcingと、新アーキテクチャの具体的な設計内容を紹介します。前回の記事はこちらから。 なぜEvent Sourcingなのか加藤潤一氏（以下、加藤）：「なぜEvent Sourcingなのか」という話で、Event Sourcingの場合はどうなっているかというと、CRUDのステートソーシングは、最新のエンティティを上書きする考え方です。Event Sourcingは、そのとき発生した変更を追記していく考え方になります。 「状態はどういうふうに作るの？」という話ですが、イベントから状態を導出する考え方です。関数にイベントをapplyして
2024.12.21 CQRS+ESカンファレンス
Amazon DynamoDB を使った CQRS イベントストアの構築 | Amazon Web Services
Amazon Web Services ブログ Amazon DynamoDB を使った CQRS イベントストアの構築 コマンドクエリ責務分離（command query responsibility segregation, CQRS）パターンは、もともとコマンドクエリ分離の原則から導出されたもので、ドメイン駆動設計コミュニティの啓蒙によって広く知られるようになったものです。イベントソーシングを使用した CQRS アーキテクチャは、イベントストア と呼ばれる追加のみを許されたログに、作成されたイベントを保存します。イベントソーシングを利用することによっていろいろなメリットがありますが、中でも次のようなことができるようになります： データベースとメッセージブローカーを跨ぐような複雑な分散トランザクション（いわゆる 二相コミットプロトコルによるトランザクション）を用いなくてもデータベースの
世の中にはクラウドを採用していても、スケーラビリティのないサービスを開発・運用しているエンジニアは少なくないと思います。過去の私もその一人でした。CQRS/Event Sourcingはその解の一つです。私自身も2016年にCQRS/ESに出会って以来、AWS上でその根本的な課題に取り組んで来ました。そ…
Kaigi on Rails 2023 (https://kaigionrails.org/2023/talks/krpk1900/) で発表した内容です。
Event Sourcing 完全に理解した
はじめに Event Sourcing を何となく理解するための記事です。 CRUD を用いた State Sourcing と比較しながら説明していきます。 State Sourcing vs Event Sourcing まず、State Sourcing と Event Soucing がそれぞれどのようなものかを挙げていきます。 State Sourcing 状態を中心に考える設計手法 現在の状態を永続化するのが一般的 CRUD(Create / Read / Update / Delete) を使って状態を変化させることが多い Event Sourcing アプリケーションの状態に対するすべての変化を一連のイベントで表現する設計手法 e.g.) 銀行の入出金履歴 イベントとは、過去に起こった出来事である An event is something that has happene
Preface
At the end of Harry’s last book, Test-Driven Development with Python (O’Reilly), he found himself asking a bunch of questions about architecture, such as, What’s the best way of structuring your application so that it’s easy to test? More specifically, so that your core business logic is covered by unit tests, and so that you minimize the number of integration and end-to-end tests you need? He mad
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
プロジェクトで境界づけられたモジュールから、コンテキストで境界づけられたモジュールへ - 弁護士ドットコム株式会社 Creators’ blog
はじめに こんにちは。弁護士ドットコムで開発をしている田所といます。 私は今年の 3 月に弁護士ドットコムへ入社し、日本最大級の弁護士/法律ポータルサイト「弁護士ドットコム」の開発に携わっています。主な役割は、レガシーシステムの改善とアジャイル開発の推進です。 本稿では、入社してから半年間で取り組んできた、レガシーシステムの改善の取り組みについて紹介します。 はじめに 「本体サイト」が抱えている課題 modulesディレクトリについて 境界づけられたコンテキストをベースにしたモジュラモノリスアーキテクチャの導入 モジュラモノリスアーキテクチャの採用 モジュール境界の設計 オニオンアーキテクチャの採用 CQRSパターンの採用 新しいモジュールに漸進的に移行する 組織全体で改善していく AIエージェント用のドキュメント整備 CIによるガードレール 出張ペアプロ まとめ 「本体サイト」が抱えてい
私たちは、中小規模システムにおけるイベントソーシングの可能性に着目し、 2022年4月から社内でイベントソーシングフレームワークの開発と運用をしています。 現在では、社内システムや受託システムを含む5つ以上のシステムにイベントソーシングを導入しています。 本セッションでは、イベントソーシングを用い…
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 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)
InfoQ Software Architects' Newsletter A monthly overview of things you need to know as an architect or aspiring architect. View an example
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
注目のITサービスを支えるアーキテクチャ特集 技術選定のポイントと今後の展望 - Findy Tools
「Rails vs Node.js」を観た｜laiso
サーバーレスマイクロサービスを構築するための設計アプローチの比較 | Amazon Web Services
なぜイベント駆動が必要なのか - CQRS/ESで解く複雑系システムの課題 -
こんなに辛いことになるから、最初にがんばろう / 辛い開発状況をどうにかするためにやった13のこと
そろそろイベントソーシング・CQRSを使ってみてもいい頃なんじゃない？
"Nintendo Switch™ 向けプッシュ通知システムのリプレイス事例" の感想
イベントソーシングから学ぶ、削除をドメインの言葉で表現する設計
実践CQRS+ES ── 小さな集約と大きな業務出力を両立する - ZOZO TECH BLOG
まずはドメインに向き合って、それからCQRSで実装する
CQRS/ESの『整合性どうするの？』に答えてみる
DynamoDBを使ったCQRS/Event Sourcingシステムの構築方法(言語・F/W非依存)
DDDにCQRSを導入する前に知っておきたいこと〜誤解しやすい4つのポイントと理想的な設計〜
CQRS & Event Sourcing - モダンアーキテクチャにおける役割と実装
「CQRSをやる」は「Event Sourcingをやる」とほぼ同義 リアクティブシステムとCQRSを反映した新アーキテクチャの設計思想 | ログミーBusiness
使いたいから使うんじゃなく「必然」として使うCQRS＋ES
AWSでCQRS Event Sourcing するにはどうすればいいのか
Fat Modelを解消するためのCQRSアーキテクチャ
２年間の実運用を経て振り返るイベントソーシングの実際
Architecting with Java Persistence: Patterns and Strategies
tsujiifarm.hatenablog.com
web.archive.org
anond.hatelabo.jp
digital.asahi.com
www.web.nhk
b.hatena.ne.jp/q