![Amazon.co.jp: :](https://cdn-ak-scissors.b.st-hatena.com/image/square/45cd30a57b54cb6e95105db6b8c783be1d20c183/height=288;version=1;width=512/https%3A%2F%2Fm.media-amazon.com%2Fimages%2FI%2F51c52CsHWTL.jpg)
業務の情報の扱い方の基本スタイルとして、 * state ソーシング * event ソーシング がある。 state が先か、event が先か、という正反対のスタイル。 state ソーシング 現在の「状態」を中心にしたスタイル。 state オンリー 一番、単純なパターン。 いわゆる「上書き」モード。 メモリ上のオブジェクトを、 setter とか update メソッドで、最新の状態を保持する。 更新前の状態は、どこにも残っていない。 テーブルであれば、update 文で、最新の状態に上書きしていくパターン。 もっとも単純だし、これで要件が満たせるなら、これで必要十分。 情報源は、「上書き」された最新の state だけ。 これが、state ソーシング のもっとも、単純な state オンリー パターン。 state - audit log パターン state を変更した時に、
前の記事で、 state ソーシングスタイルと、event ソーシングスタイルについて書いた。 単純にいえば、メモリ上でオブジェクトを操作する順番、そして、データベース操作の順番の問題。 state ソーシング state ( 現在の状態 ) オブジェクトの更新が最初。 必要が、あれば、audit ログ(監査記録)とか、history ( 履歴 ) オブジェクトを作成する。 テーブルであれば、state テーブルを update すると、トリガー で、監査テーブルにレコードを insert したり、history テーブルに insert する、というやり方。 顧客の連絡先、例えば、住所を変更したら、住所変更ログを書いたり、住所変更履歴を作成する、というパターン。 event ソーシング ビジネスの事象オブジェクトを作成する。 そのオブジェクトが、しかるべき、state オブジェクトを変化
This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway. 3. Challenges discussed were managing 30 microservices, ensur
前提 私は「エリック・エヴァンスのドメイン駆動設計」を読んだのみで、「実践ドメイン入門」は未読(とても欲しい)の状態で書いています。 (「実践ドメイン入門」にはもっと深い洞察が書いてあるのだと思います…) また「エリック・エヴァンスのドメイン駆動設計」と共に、参考リンク先をまず読んだことがある前提で書いている部分がありますのでご注意下さい。今後もっと良いアイデアが浮かんだり、実際に実装するにあたって浮かび上がった課題があれば随時追記・記事にできればいいなと思います。 参考 CQRS Documents by Greg Young Greg Young流CQRS - Mark Nijhof CQRS+ES DDDから更にData Flowの概念を取り込んだarchitecture。 コマンドクエリ分離原則(CQS/Command Query Separation)に基づく。 CQRSは Co
書き込みと読み込みのどちらに力を入れているかは、ストレージエンジンによって異なります。たとえば昔ながらのリレーショナルデータベースは、外部キーなどの制約を使ってデータの整合性をうまく制御できるようになっています。一方でNoSQLデータベースは、スループットとスケーラビリティを確保するために、そういった組み込みのガードレールをはずしてしまいました。データ層においても、どちらか一方に特化した最適化をすることがあります。たとえば、あらかじめ計算済みの値を保持しておけば、「一日あたりのサイト訪問者数」などの読み込み操作を効率よく行えるでしょう。ストレージソリューションのメーカーはどこも、「うちのプロダクトならあらゆるニーズを満たせます」などと自社製品の機能を自慢します。しかし実は、昔ながらのCRUDモデルに沿ってストレージエンジンを選んでデータ層を設計した時点で、さまざまな関心事の間で何らかの妥協
この記事は、はてなデベロッパーアドベントカレンダーの19日目の記事です。 昨日は、id:t_kyt による あれから一年、あの TypeScript プロジェクトは今 - 多幸感 でした。 すばやく、かつ堅牢にアプリケーションをつくる ボタンを連打したくなる性と向き合う サーバサイドにおける工夫 イベントソーシング リクエストに複数のリソースを含められるように クライアントサイドにおける工夫 イベントのバッファリング accumulate-call で簡潔に書く むすび すばやく、かつ堅牢にアプリケーションをつくる はてなの id:aereal です。アプリケーションエンジニアとして日々、サービスの開発に携わっています。 はてなではサービス開発合宿が年に一度ほどのペースで開催されています *1。今年もつい先日開催されました。 私たちのチームは技術的な挑戦を行う一方で、プロトタイプではなく初
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く