本日の作業
本日は鎌倉もくもく会183回目でした。
✅ Supabase Authの設定
✅ Mail認証, SSO認証の設定（Github, Google）
🚴 分報に関する設計・実装
🚴 Server側のDomain Eventの実装
🚴 Database（Prisma）の設計・実装
🚴 テーブル設計
🚴 分報と関連テーブルのSchemaの実装
🛑 Supabase導入のまとめを書く（休日にやる）
🛑 🚴 イベントストーミングとサービスブループリンの融合についてzennにまとめる（休日にやる）
Supabase Authのセッションについて
RemixでSupabase Authを使う場合はこちらを見ると良さそう
Supabase AuthにはRemixなど（Next.jsも）用にHelperが用意されているのでそれを使うのが早そう。
Client Side
上のドキュメントだとOutletのcontextで渡しているが、そもそも認証が必要なroutesをHoCするか、認証用のContextとContext Providerを用意して必要なところでwrapするのが良さそう
Server Side
Session Cookieで実装するのが一般的でloader内で処理
Databaseとの連携はcreateServerClientでまとめられるぽい。
Firebase同様にService Workerでfetch毎にSession Storageを見る方法もできると思う。この方がキャッシュ戦略的にも良さそうな気がするし、loader/actionを介さない通信にも組み込めるので余裕できたら対応しようと思いますが、createServerClientなど割とSDKで良しなにやってくれるぽいので今はいいかな。
イミュータブルデータモデルでのテーブル設計
イミュータブルデータモデリングでは、データの変更を追跡するために変更不可能なレコードを使用します。出来事を記録し、それぞれのイベントに全ての属性とタイムスタンプを持たせるイベントエンティティから任意の時点でのデータの状態を正確に再現でき、データの整合性と変更履歴の追跡を容易にできる。らしい。
イミュータブルデータモデルは集約に対してリソースエンティティとイベントエンティティとある。
イベントエンティティには日時を複数持たせない。持たせたくなったらイベントの単位が大きい可能性があるので適宜分割する。またイベントは時系列に発生するので時系列で捉える。
リソースエンティティはイベントの主たる情報で日時を持たない。持ちそうになったらそこにイベントエンティティが含まれている可能性がある。
ブログ記事で事例を考えてみる
例えば、「ブログ記事を作成した」「ブログ記事を編集した」と言うドメインイベントがあるとするとテーブルはとりあえずは次の3つ。
作成したイベントエンティティのテーブル => created_artcles
作成した人（オーサーユーザ）・タイトル・内容を持つ。
変更したイベントエンティティのテーブル => edited_articles
変更したタイトル・内容を持つ。
タイトル・内容いずれかのみ変更の場合はどうするのだろう？
ブログ記事のリソースエンティティ => articles
日時系のデータは持たず、いわゆるコアになる属性（カラム）のデータの最新状態を持つ。
で、次のようなリレーションになる認識。
ここで懸念。例えば更新順の記事一覧を取得するとなるとcreated_articlesとedited_articlesをjoinしてcreated_atまたはupdated_atの日付を比較して最新のもののarticles_idから記事を取得し、日付と合わせて返すとかしないといけない？だとすればこの程度ならパフォーマンスにはさほど影響はなさそうだけど、ものによってはどうなんだろう？という印象。
ちょっとその辺は明日以降に調べていきます。
その他、メモ
Event StormingとDomain Model Made Functionalとイミュータブルデータモデリングを手を動かしつつ学ぶとこの辺の効果の高さみたいなのが伺い知れて良き。今回はServer SideをDMMFで実装する様にしているのとデータベースも設計から自分がやっているので（仕事でもデザインからデータベース設計・実装までトータルにやる時の方が多いけど）こういうの導入できるけど、これがスキルセットがバラバラなチームで実装担当が完全に分かれてたりするとちょっと導入は難しいのかなと。