20250320 メモ
今日は思考が分散した。読んだ文章に含まれるワードから色々連想することが多かった。
usecase, service層は理想的にはドメインモデルのI/Fを呼び出して協調させることだと思うけど、トランザクションスクリプト化していることが多いのかもしれない。
「ビジネスを継続的に発展させていきたい」から、継続的に安定した開発を可能にする必要があって、そのために備えたい品質特性として例えば保守性があって、それを高くしたい、だからDDDを採用するとか、クリーンアーキテクチャを参考にアーキテクチャを組む、というふうに考えると納得感ある。ビジネスのあるべき姿から逆算して技術を使ったり技術で解決するというのはこういうことなのかなとふと思った。
Transactional Outboxパターン。トランザクションの中でoutboxテーブルにインサートすれば、信頼性あるよねっていうのが少しモヤる。その後のメッセージブローカーからコンシューマーにメッセージが渡って意図した形で消費されるという確実性はどのように担保するのか？
=> メッセージブローカーはたぶんストリーミングサービスを使うことになり、そのサービスの作りを信頼する感じになりそう
=> コンシューマーの処理は自前で組むので、信頼性をもたせられるかは腕の見せどころ（？）
コンシューマーはメッセージを消費するにあたって、メッセージブローカーをポーリングしている？それともメッセージが渡ってくるのを待っている？（メッセージブローカーがコンシューマーを叩く？）
=> PubSubであれば メッセージブローカーが指定されたコンシューマーに対して配信を行う。ファンアウトが可能。Amazon SNSなど。
=> Producer/Consumerであれば コンシューマーがメッセージブローカーをポーリングする。Amazon SQSなど。
Publisher-SubscriberとProducer-Consumerはそれぞれ非同期メッセージングにおける選択肢。
https://dev.to/dsysd_dev/do-you-understand-publisher-subscriber-vs-producer-consumer-pattern-differences-2nh3
上の記事だとProducer-Consumerパターンにはメッセージブローカーが登場しないことになっていて、代わりに共有バッファが出てくる。ちょっと違うかもしれん。
ちょっとメリデメ比較はあとでやる。
サーガ、TCC、2PCなどをなるべく採用しないという方針があるけど、それらのパターンをどうしても許容しなければならないときが仮にあるとしたら、それはどんなときなんだろう？