先日開催された吉祥寺.pm18で「ぼくがかんがえたさいきょうのSoR/SoEあーきてくちゃ」というテーマで発表をしてきました。
そのイベントレポート兼発表補足です。
イベント概要
スライド
発表内容の補足
Twitterやはてブ等でいくつかご意見いただいているので、それについて現時点で僕が考えていることを補足させていただこうと思います。ひとつ言い訳させてもらえるなら、今回は時間が短すぎたので結構前提となる説明（エヴァンスさんの DDD を僕がどう捉えているか、CQRS とは何か、等）を省略したところが多すぎたかなっていうのがあり、特に当日いらっしゃらずスライドだけを見ていただいた方には余計にわかりにくかったかもしれないので、ここで FAQ 形式で補足させてもらえればと思います。
整合性に関しては DDD でいう Aggregate がその単位じゃないの？そもそも SoR/SoE って整合性で分類するものなの？
これについては Twitter に書きました。
きちぴーのブログ書いて発表の補足したほうがよさそうだなってなってる
— すえなみさん🍖💰＠アイコン作ってもらった (@a_suenami) 2019年5月18日
あの発表は10分しかないから整合性の話を取り上げただけで、整合性のあり方によってSoR/SoEを分割するっていう意図はまったくなかったのです。エヴァンスさんだって集約の外は結果整合でいいって言ってるわけですし。
— すえなみさん🍖💰＠アイコン作ってもらった (@a_suenami) 2019年5月18日
SoR的なのかSoE的なのかはあくまで各要件（性能要件、リリース頻度等の運用要件、UI要件等）をもとに検討するべきで、その結果としてSoE的だなって判断したのであればできるだけ結果整合性に寄せれるように考えましょうっていう話です。
— すえなみさん🍖💰＠アイコン作ってもらった (@a_suenami) 2019年5月18日
スライド中に出てくるシーケンス図がEvent Sourcingを前提にしているように見えますが、それも強い前提とは思ってなくて、ただ非同期でリトライ可能（つまり冪等）にしておいたほうが耐障害性が高まるかなとは思ってます。RESTful APIでPOSTするとかだとSoR側が死んでるときにSoE側も死んじゃうので。
— すえなみさん🍖💰＠アイコン作ってもらった (@a_suenami) 2019年5月18日
DDD の Aggregate を整合性境界とする考え方は僕は SoR 的というか、データストアの都合に強く引っ張られていると思っています。多くのシステム利用者にとっての整合性境界は「画面」とか「セッション」、クリーンアーキテクチャでいうと Usecase のレイヤーで、たとえば「商品購入と同時に会員登録」というユースケースがあったとき、実際には会員と商品が集約ルートとしてあって別のトランザクションが実行される（その間は結果整合性しか保証されない）と思うんですが、利用者の目に触れるところで「会員登録はできたけど購入履歴には購入したはずの商品が見えない」という状態は許容されないのです。他の利用者はともかくとして、少なくともその利用者本人にとってはすべてが完了した状態であるべきという話です。
要するに、実際には結果整合性しか保証されないものをあたかもトランザクション整合性が保証されてるように見せかける（さもなくば「処理中」「確認中」というステータスを SoE 側の都合で導入して、利用者にきちんと納得してもらえるタッチポイントを提供する）というか、そういったユーザ体験の観点からの不安の除去や状態の説明が SoE の仕事なんです。
エンジニアにとっては同じ結果整合性でも利用者自身がそれを認識しているかどうかという別の観点があって、数ミリ秒から数秒程度で整合性のとれた状態になるのであればそれは利用者にとってはトランザクション整合性と事実上同じに見えるでしょうし、数分やそれ以上かかるのであれば Engagement を担うシステムとしては「少々お待ちください」的なメッセージを伝える必要があるでしょう。
あまり具体的な実装の話はしませんでしけど、「ユーザローカルな整合性」と呼んでるものって具体実装でいうと Redux の Store や Reducer をどういう風に設計するかっていう話で、それがサーバーサイドと必ず同期されているべきかというと別の話って感じですかね。（BFFがある場合、そこくらいまでは同期されてて欲しいけど、ここでいうサーバーサイドっていうのはさらにその後ろによくいるマスターデータとなるデータストアを司ってるやつのことです。）
期限付きの予約をできる必要がある
これは要件によるとしか言えませんが、大抵の場合はその通りですね。
ただ発表者である僕自身がライトヘビーでシビアなシステムに関わってないので、切実に困っているわけでなく、そういう意味で明確な成功体験も失敗体験もなくて今回の発表からは割愛した感じです。
SoR / SoE という名前は適切ではない
これは実は僕も思っているのですが、僕程度の人間が独自の命名をするよりも世の中に広く知られている分類方法を使ったほうがいいかなぁ、と思った次第です。たぶん今後もこの言葉使うと思います。
話せなかったこと
まあ、整合性のとり方について以外はほぼ話せなかったんですが、たとえばもっとこういう話に掘り下げていけるといいなと思っています。
- チームのあり方
- 具体的なAPIエンドポイントやデータストアの設計について
- それぞれに適したアーキテクチャ
- 既存システムからのリストラクチャリングプロセスなど
感想とか
吉祥寺.pm 初参加だったのですが、発表内容が多岐に渡り、いろんな人がいるいい会だなーと思いました。（こなみ）
一番の反省は句会であるということをまったく認識しておらず、当日に慌てて一句詠もうとしたのですがまったくいい句が出来ず僕だけ短歌になってしまったことです。次に発表するときには会心の一句を準備して臨みたいです。
Tips
懇親会後の三次会（？）でそーだいさんっていうこわい人から「おい！ラーメン行くぞ！！」って言われて「ひええ」と思いながら一風堂という名店へ何人かで行ったのですが、とんこつ豆腐（麺の代わりに豆腐が入ってる）という神メニューがあったのでもうシメのラーメンこわくないです。そーだいさんはこわいけど。
