タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
マイクロサービスのための分散データ 〜 イベントソーシング vs チェンジデータキャプチャ - 赤帽エンジニアブログ
インテグレーションのためのミドルウェア製品のテクニカルサポートを担当している山下です。 今回は レッドハットのシニアアーキテクトである Eric Murphy さんによる「マイクロサービスのための分散データ 〜 イベントソーシング vs チェンジデータキャプチャ(CDC)」の翻訳記事です。この記事では、イベントソーシング、CDC、CDC + Outboxパターン、CQRSをそれぞれ簡単に説明しながら、それらの特性の違いを比較します。また、イベントソーシングとCQRSの簡易な説明がなされている他、あまり明確に語られることが少ないもののソフトウェアの設計に大きな影響をおよぼすドメインイベントとチェンジイベントの違いにも触れられています。 [原文] Distributed Data for Microservices — Event Sourcing vs. Change Data Captur
認知的複雑度から見るGo言語のイベントソーシング実装 / Event Sourcing with Go
Go Conference mini 2022 Autumn IN SENDAI の登壇資料です。
イベントソーシング（ES）って何？ イベントソーシング（以降、ESと呼ぶ）とは、かなり端的にいうとCRUDにおけるU（update; 更新）とD（delete; 削除）を使わないでアプリケーションのステートを管理する手法のことである。 なぜ使わないかというと、データの更新と削除は本質的に「情報を消し去る」操作であり、消し去った情報が後々ビジネス価値のあるものだと気づいたとしても泣き寝入りするしかないからだ。 ESにおいては、データの更新や削除をするかわりにアプリケーションが管理するステートに対してどのような操作が行われたかをappend-onlyのイベントログに記録していき、ある時点でのステートを知りたいときはアプリケーション側でイベントログの内容を元にステートを導き出すという方法を取る。 CRUDとESの比較 例えば、「ユーザーがパスワード変更する」場合、よくあるCRUDパターンでは u
「FinOps、アプリケーション単位の経済性、クラウドコストの最適化について、ロワ・ラヴホン氏語る」 このエピソードでは、Finoutの共同設立者兼CEOであるRoi Ravhon氏が、InfoQポッドキャストの共同ホストであるDaniel Bryant氏と対談し、FinOpsの出現と業界の採用について議論した。この対談では、FinOpsを採用するメリット、クラウド・コストについてもっと知りたいと考えている組織の典型的な道のり、実装を成功させるために必要な様々な文化やツールといったトピックが取り上...
突撃！隣のデータ設計・活用勉強会 vol.1の登壇資料です。 https://stafes.connpass.com/event/273805/
この記事を書くに至った背景 株式会社ジェイテックジャパン CTOの高丘 @tomohisaです。昨日、イベントソーシングのイベントについて以下の記事を書きましたが、この記事はフォローアップ記事です。よろしければ元の記事もご覧ください。 2023/12/17追記: ジェイテックジャパンで開発してきた、イベントソーシング・CQRSフレームワーク、「Sekiban」をリリースしました！ www.sekiban.dev/jp/ こちらの記事にかとじゅんさんから適切なコメントをいただきました。 イベントは事実であって、世界は事実の総体であり、事物の総体ではない。とても上手くまとめてくださっています。私もイベントソーシングを使い始めて、オブジェクト指向で考えるより、イベント（事実）を中心にモデリングしていく方が複雑な事象をモデリングしやすいと感じています。さらに新しい事象、事実のパターンに気がついた時
マイクロサービスでイベントソーシングを利用したくなる理由とその動作原理を学ぼう / Why Event Sourcing
イベントソーシングがなぜ必要になるのかの解説と、その動作原理を解説する際に利用した資料です。 この資料を使ったトークが YouTube にアップロードされています。 トークURL: https://youtu.be/Jtcp9ry8ZcE ◆ URL トークURL: https://youtu.be/Jtcp9ry8ZcE チャンネル登録: https://www.youtube.com/c/narusemi?sub_confirmation=1 Twitter: https://twitter.com/nrslib SampleCode: https://github.com/nrslib/microservice-with-event-sourcing-sample-kotlin
TL;DR; 殆の場合において論理削除は不要。素直にRDBの機能を使うかイベントソーシングパターンを導入する。 なんで今更論理削除の話を？ 散々議論されていて皆さん飽き飽きしている話題だと思いますが、今一度個人的にまとめたかったからです。 実際にできる/できないではなく、テーブル設計的にあるべき姿かどうか・実装運用時にどうなるかに重きを置きます。何度か論理削除を利用したプロダクトに関わった経験に基づく個人的な感想です。PostgreSQLベースです。 そもそも論理削除とは RDBのテーブルに「削除済み」を意味するカラムを追加することで、DELETEを発行せずに論理的に削除を表現する手法です。良くある実装には、Booleanのフラグで表現するものと、削除タイムスタンプ (削除されていない場合はNULL) で表現するものがあります。これに加えて、論理削除されたレコードが見えないようにしたVie
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SQLでもイベントソーシングはできるという話 - Qiita
イベント駆動からイベントソーシングへの移行 - MicroCPHのFangel, Ingerslev両氏の講演より
Debeziumを活用した RDBMSイベントソーシングの仕組み
「イベントソーシング」の「イベント」というワードチョイスは適切なのか？
論理削除について再考、そしてイベントソーシングへ - 水底
ascii.jp
www.japan-ems.jp
unevieconfortable.com
mobile.hamic.ai
qiita.com/watanabe_kippei
majo-terrace.online