MBC CQRS サーバーレス フレームワーク の解決出来る課題1

MBC CQRS サーバーレス フレームワークを採用することにより解決出来る課題について考えてみます。
例えば弊社では下記の様な課題を抱えておりました。

大量の更新処理・読込処理が競合してシステムエラーが発生していた

ある受注管理システムでPDF生成処理をしながら別の担当者が同データを読込していた等が同一データを読込と書き込みが教護する事態が発生していました。
そのような処理が発生するシステムでは読込と書き込みを別のDBに行う事が出来るCQRSモデルで解決出来ると考えました。

誰がいつどのように変更したか調査をしてほしいと依頼を受けたが調査が困難

ログをシステムに組み込みログを検索できるようにすれば上記課題を解決できますが、全機能で同様の実装が同品質で組めるかというとかなりのコストがかかるのではないかと思います。
CQRSモデルを採用するとデータの更新処理はコマンドを実行することになるため、コマンドの履歴が標準的に残されていることになります。
コマンドはデータの追加・更新内容を時系列で蓄積しているため処理を時系列で追っていくことが出来トラブル発生時に正確な状況を捉えることが可能です。

他の人がデータを更新したことを知らずにをデータを上書きしてしまった

簡易的なシステムを実装しているとデータのロックを疎かにしていることがあります。そのようなシステムの場合ユーザ数も少なく不具合が発生することも少ないのですが時折データが誤って上書きされると問題になることがあります。
MBC CQRS サーバーレスフレームワークでは楽観的ロックを実装しているため誤ってデータが上書きされることはなくなります。
楽観的ロックはレコード内にバージョン番号を埋め込んでおき、コマンドはバージョン1から順番に受付を行います。新しいコマンドを実行する場合は現在のバージョン番号プラス1となりますが、同じバージョン番号を受け付けることは出来ないため必ず最新版のデータを参照してから新しいバージョンを採番しコマンドを受け付けます。

ユーザが画面を開いていてレコードを読み込んでいた場合はどうすれば良いでしょうか？

その場合はAppSyncにてレコードが更新された旨の通知をそ送信しておりますのでフロント側で更新通知を受け取ったら最新データを取得する or そのまま続行する(場合によっては差分を表示する)とったじっそうを行なう事も出来、ユーザビリティは向上します。