はてなまとめ - 複数集約を跨ぐ処理を1つのDBトランザクションで括る前に読む記事

1: nguyen-oi 2026/05/21 23:12

安易にトランザクションで括るとデッドロックやHistory list lengthで死ぬのわかる

2: prograti 2026/05/21 23:36

単一DBトランザクションのリスクが顕在化するケースは少ないかもだけど、アーキテクチャが過剰になることを抑えながらバランスを取るための前提知識として、前半の設計論は意識しておきたいですね

3: for-my-internet-demo 2026/05/22 00:46

何にでも補償トランザクションアーキ持ち込む最後の方の人になってしまった

4: daaaaaai 2026/05/22 06:53

DDD本のひっかかりが整理されてよい！ただ、単一トランザクションのコストとリスクがDBのパフォーマンス・ロック待ち程度なことと、プロセスマネージャがトランザクションスクリプト化しないかとか気になりました

5: nakag0711 2026/05/22 07:55

しないですむならそれに越したことはないが今回の例が原理的に間違いのようには見えないかな

6: soxandcity 2026/05/22 08:45

チーム全員が理解してかつ納期にコミットしてくれるならOK

7: Error401 2026/05/22 08:50

AしてBしてCが失敗したのでBを戻してAを戻そうとしたら失敗した、みたいなこと考えたくないじゃないですか。

8: umai_bow 2026/05/22 10:36

補償トランザクションは大変なのでリトライで解決できるような仕組みにできないか考えるのもよいとおもう

9: nil0303 2026/05/22 14:55

理屈はわかるんだけど過剰になり過ぎるケースの方が多いような。別に単一トランザクションで問題起きないようなものにもこのアーキテクチャ導入するのはコストが合わない。

10: sin20xx 2026/05/22 15:19

様々なコストとのトレードオフでは。メンバーの理解度が均一である前提だと思うが、現実的にはそうではなく、その上で一つの認識違いから致命的な障害であったり不整合になる事態について本当に保証できるのかという