本日の作業
🚴 分報・日報・ユーザに関する設計・実装
✅ テーブル設計の見直し
🚴 Database（Prisma）の実装
Server側のDomain Eventの実装
サインインの実装
認証画面実装
認証ロジック実装（主にClient側）
Server側の認証チェック実装
Client側の認証チェック実装
🛑 🚴 イベントストーミングとサービスブループリンの融合についてzennにまとめる（次のもくもく会で書く予定）
テーブルの見直し
EventSorcingについて学習している過程で、前回イミュータブルデータモデリングでまとめたテーブル設計に違和感を感じたので見直しました。
どこに違和感を感じたか？
イベントエンティティ毎にスナップショット的なカラムが用意されていたところ。
本当に日報のイベントエンティティは「作成・編集・削除」なのか？
まず、「スナップショットであるべきか？」についてはNoで、例えば削除については日報のタイトルや内容（コンテンツ）を含めず単に削除されたリソースIDと日時または物理削除か論理削除かのステートを持つ様にする。
変更については明示的にどれが変更されたかを残す。例えば次のようにする。
日報の編集エンティティテーブル
日報リソースID
変更のあった要素（["title" | "contents"]）
タイトル
内容（本文）
変更日時
さらに、本文の差分を管理するとなるとこんな感じ。
日報の編集エンティティテーブル
日報リソースID
変更のあった要素 [ "title" | "contents" ]
タイトル
内容（本文）の変更箇所 { 行番号, 文字列の位置 }
内容（本文）の差分 {diff形式}
変更前の内容（本文）
変更後の内容（本文）
変更日時
日報のイベントエンティティは「作成・編集・削除」なのか？
編集・削除は変わらないと思います。作成については日報は作成というのか？という点です。「日報を記録した」とか「日報を書いた」はあり得るけど「日報を作成した」とはあまり言わない様に思います。
また、ライフサイクル的に編集も「記録した」「書いた」に入ると思うのでそう考えると「日報を記録を開始した」というドメインイベント後に「日報を編集した」があるのではと思いました。
その辺踏まえてEvent Stormingから見直し。ついでに日報もEvent Stormingしてみました。
Event Sourcingでのテーブル設計見直し
イミュータブルデータモデリングでリソースエンティティとイベントエンティティでテーブルを分けて振る舞い毎に記録を残し、その記録を辿って集約の状態を復元することでデータの変遷を追跡可能になるわけですが、例えば作成と変更・削除とイベントがそれぞれあってそれぞれのテーブルが存在する場合に、各イベントの変遷を見るには2つの方法が必要になります。
イベントテーブルをjoinして日時順にソート
イベントストアテーブルを用意して発生イベント順でリレーションしていく
パフォーマンスとSQL的には後者が有効そうなのでイベントストアテーブルを用意します。
次のものがここまでのまとめを踏まえて定義したテーブルです。どこが変わったかが過去のものが見れないので比較がしにくいですがまぁそれはしゃーない。
その他、メモ
このしずかなインターネットのフォーマットを見返すと、日報にはその日のタスクを載せたり、そのまま次の日報に終わってないやつ引き継げたりすると良さそう。毎回コピペしてるけどだるい。しかしとなるとTodoが必要になるなー。
ちなみにタスクに載せたがやっぱやめたとかを柔軟にできるようにしたい。出ないと迂闊に消せないとか消すハードルが上がるといつまでもタスクが残る。後回しでもいいものは躊躇なく消すでいいと思う。
尚、Kanbanやプロジェクト管理はGithub Projects使っておくれで良くてこのサービスはもっと開発におけるパーソナルな部分にフォーカスを当てた方がやっぱり良さそう。
あとEvent Sourcingを勉強してて思ったけど、日報の変更差分履歴はデフォルトは使えずにしてプロプラン的なやつで課金ポイントの一つにしたらいいのではと。まぁどっちにしても記録するので課金しない間は残さないとかもありなのかもしれないけど…整合性がどうなるか微妙なのでちょっと考えもの。