#kichijojipm先日開催された吉祥寺.pm18で「ぼくがかんがえたさいきょうのSoR/SoEあーきてくちゃ」というテーマで発表をしてきました。そのイベントレポート兼発表補足です。イベント概要kichijojipm.connpass.comスライドspeakerdeck.com発表内容の補足Twitterやはてブ等でいくつかご意見いただいているので、それについて現時点で僕が考えていることを補足させていただこうと思います。形式で補足させてもらえればと思います。2019年5月18日あの発表は10分しかないから整合性の話を取り上げただけで、整合性のあり方によってSoR/SoEを分割するっていう意図はまったくなかったのです。エヴァンスさんだって集約の外は結果整合でいいって言ってるわけですし。2019年5月18日SoR的なのかSoE的なのかはあくまで各要件(性能要件、リリース頻度等の運用要件、UI要件等)をもとに検討するべきで、その結果としてSoE的だなって判断したのであればできるだけ結果整合性に寄せれるように考えましょうっていう話です。Sourcingを前提にしているように見えますが、それも強い前提とは思ってなくて、ただ非同期でリトライ可能(つまり冪等)にしておいたほうが耐障害性が高まるかなとは思ってます。APIでPOSTするとかだとSoR側が死んでるときにSoE側も死んじゃうので。的というか、データストアの都合に強く引っ張られていると思っています。レイヤーで、たとえば「商品購入と同時に会員登録」というユースケースがあったとき、実際には会員と商品が集約ルートとしてあって別のトランザクションが実行される(その間は結果整合性しか保証されない)と思うんですが、利用者の目に触れるところで「会員登録はできたけど購入履歴には購入したはずの商品が見えない」という状態は許容されないのです。他の利用者はともかくとして、少なくともその利用者本人にとってはすべてが完了した状態であるべきという話です。担うシステムとしては「少々お待ちください」的なメッセージを伝える必要があるでしょう。いう風に設計するかっていう話で、それがサーバーサイドと必ず同期されているべきかというと別の話って感じですかね。(BFFがある場合、そこくらいまでは同期されてて欲しいけど、ここでいうサーバーサイドっていうのはさらにその後ろによくいるマスターデータとなるデータストアを司ってるやつのことです。)期限付きの予約をできる必要があるこれは要件によるとしか言えませんが、大抵の場合はその通りですね。発表者である僕自身がライトヘビーでシビアなシステムに関わってないので、切実に困っているわけでなく、そういう意味で明確な成功体験も失敗体験もなくて今回の発表からは割愛した感じです。いう名前は適切ではないこれは実は僕も思っているのですが、僕程度の人間が独自の命名をするよりも世の中に広く知られている分類方法を使ったほうがいいかなぁ、と思った次第です。今後もこの言葉使うと思います。話せなかったことまあ、整合性のとり方について以外はほぼ話せなかったんですが、たとえばもっとこういう話に掘り下げていけるといいなと思っています。初参加だったのですが、発表内容が多岐に渡り、いろんな人がいるいい会だなーと思いました。(こなみ)一番の反省は句会であるということをまったく認識しておらず、当日に慌てて一句詠もうとしたのですがまったくいい句が出来ず僕だけ短歌になってしまったことです。次に発表するときには会心の一句を準備して臨みたいです。Tips懇親会後の三次会(?)でそーだいさんっていうこわい人から「おい!ラーメン行くぞ!!」って言われて「ひええ」と思いながら一風堂という名店へ何人かで行ったのですが、とんこつ豆腐(麺の代わりに豆腐が入ってる)という神メニューがあったのでもうシメのラーメンこわくないです。だいさんはこわいけど。見極め方Archiveスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。