本日の作業
🚴 分報・日報・ユーザに関する設計・実装
🚴 Database（Prisma）の設計・実装
✅ テーブル設計
🚴 分報と関連テーブルのSchemaの実装
Server側のDomain Eventの実装
サインインの実装
認証画面実装
認証ロジック実装（主にClient側）
Server側の認証チェック実装
Client側の認証チェック実装
🛑 🚴 イベントストーミングとサービスブループリンの融合についてzennにまとめる（次のもくもく会で書く予定）
Database設計
とりあえず今見えている範囲のDatabase設計しました。インデックスなどはまだユースケースが見えないので貼ってないです。設計の元になったのはイミュータブルデータモデリングです。
〈R=Resouce〉 〈I=中間テーブル〉 〈E=Event〉
ユーザアカウント ─ user_accounts 〈R〉
ユーザアカウント登録 ─ user_account_event_registed〈E〉
ユーザアカウント更新 ─ user_account_event_update〈E〉
日報 ─ dailys〈R〉
日報追加 ─ daily_created〈E〉
日報編集 ─ daily_edited〈E〉
日報削除 ─ daily_deleted〈E〉
分報 ─ minutes〈R〉
分報追加 ─ minutes_created〈E〉
分報編集 ─ minutes_edited〈E〉
分報削除 ─ minutes_deleted〈E〉
日報に含まれる分報 ─ daily_minutes〈IR〉
日報へ分報追加 ─ daily_minutes_added〈E〉
日報から分報を削除 ─ daily_minutes_removed〈E〉
* removedとdeletedの違いはremoved = 削除後に再度追加があるもの、deletedは削除したら戻らないもの
こうやってテーブル定義すると変更・削除がいつどのように行われたのか自然と残るなーと。あとはDMMFのイベントを純粋関数で表現する際にその中でprismaを経由してこれらのリソース・イベントをトランザクションはって扱えば良いのではと今のところは思ってます（実装してみないことにはわからないけど）。
尚、中間テーブル以外のリソースにupdated_atを常に持たせてますが、これはリードモデルとして扱う際に変更日のデータも必要だけどイベントから精査して日付を取得するのは色々面倒そうなのと、リソースは最新の状態とするという点も加味してそうしています。マサカリ飛ばされそうな気もするけどこれをどうするべきなのかがわからないのでそうしています。
もしかしてイベントソーシングとかが関係するのか？とか思っているけどイベントソーシングを詳しく知らないので進めながら必要であれば学ぶ予定。出ないといつまで経っても実装ができない😂
というわけで、明日はこのテーブルの内容をprisma schemaに書いていきます。てか、dbdiagramのスキーマから自動でどうにか変換できそうな気もするんだけど…。
その他、メモ
仕事の方でサービスのLPを作るためにUnsplashとかiStockとかでイメージ探し。生成系AIでイメージを作るかと思うけど今ひとつ人間を作るとキモ口なるかAIぽくなるかだし、細かい表現をプロンプトで書くのが難しい。何か探すのにサクッとできないものかなー。
分報と日報の画面ができてデータのやり取りができるようにするところまでやったらクローズドαとしては一応一区切り。そのあとはクローズドβで何人かに声かけて使ってもらうまで進める。その間にLP作って早期ユーザ集めを始め、クローズドβで課題になった点と不足しているものをパブリックβで開発し早期ユーザ向けにリリース… この辺で安定してきたなってのと運用資金面で問題なさそうなら正式リリース…という感じで計画中。多分なんや感や正式リリースは早くても年末くらいではないかと思う。
ていうのをNotionに全部書いてたりする。絵に描いた餅にならないように日々精進。あと関係ないけど多分受かるレベルはとうに過ぎているのにいつまでも受けていない馬場馬術2級ライセンス取る。そして今も出てもおかしくないのに頑なに出ない部内の競技会に出る。と。