Railsで"脳に優しい"シンプルなイベント駆動システムを構築しよう（翻訳）｜TechRacho by BPS株式会社
概要 元サイトの許諾を得て翻訳・公開いたします。 英語記事: Event sourcing for smooth brains: building a basic event-driven system in Rails | Boring Rails: Skip the bullshit and ship fast 原文公開日: 2024/07/21 原著者: Matt Swanson サイト: Boring Rails 日本語タイトルは内容に即したものにしました。 イベントソーシング（event sourcing）といえば、専門用語が山盛りでややこしく、多くの開発者にとって理解しにくいものです。基本的な概念を説明するときにも「集約ルート（aggregate root）」や「投影（projection）」といった難解な用語が飛び交いがちです。 ハイレベルな「完全装備のイベントソーシング」で
株式会社ジェイテックジャパン CTOの高丘 @tomohisaです。この記事は私たちジェイテックジャパンの作成しているイベントソーシング・CQRSフレームワークがリリースされてしばらく経ったので開発に至るきっかけやこれまでの歴史をまとめてみました。 Sekiban開発に至る経緯 複雑さに対応するアーキテクチャの必要性 当初、私たちはシンプルなMVCで開発を行っておりました。しかしながら、Fatコントローラーが生じる問題や、モデルにビジネスロジックをまとめる難しさから、メンテナンスが困難なシステムへと変化してしまいました。 そこで、弊社ではDDDというドメイン駆動設計を導入しました。初期段階では「軽量DDD」もしくは「とりあえずレイヤー化したオニオンアーキテクチャ」でした。しかし、リポジトリの抽象化によって、コードのテストが劇的に書きやすくなりました。また、多くのビジネスロジックがドメインに
1. ストリーム処理とバッチ処理の基本概念1.1 バッチ処理とはバッチ処理は、一定期間に蓄積されたデータを一括で処理する方式です。典型的には、1日、1時間、またはそれ以上のスパンでデータを集め、その後一度に処理を行います。 バッチ処理のメリットは、データを一気に処理するためスケーラビリティが高く、リソースの使用効率も比較的高いことです。 また、システムの停止やエラーが起きた際にリカバリーが比較的容易です。しかし、リアルタイム性がないため、即時反応が求められるケースには不向きです。 バッチ処理のメリット: 大量のデータを一括で処理できる。 処理の実行タイミングを自由に調整できる。 システム障害やエラーのリカバリーが容易。 バッチ処理のデメリット: リアルタイム処理ができない。 大量のデータが一度に処理されるため、ピーク時の負荷が高くなる可能性がある。 1.2 ストリーム処理とはストリーム処理
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
イベントソーシングフレームワーク、Sekibanの開発に至る経緯と開発中の試行錯誤
ストリーム処理とバッチ処理の比較と運用における注意点｜zono