本日の作業
本日は鎌倉もくもく会 #182
✅ Event Stormingについて再度学習・実践
🚴 分報に関する設計・実装
🚴 Client側のUseCaseの実装
🚴 Server側のDomain Eventの実装
Database（Prisma）の設計・実装
Supabaseの設定と開通
Supabase Auth
Supabase Database
🛑 🚴 イベントストーミングとサービスブループリンの融合についてzennにまとめる（休日にやる）
Event Storming（イベントストーミング）でモデリングしてみた
Event Stormingについては下の記事を参考にした。
分報でモデリングしてみる
分報の概念については次の定義。
分報の概念
開発日誌はある一定の期間（1日や1回の作業など）のワーク（作業）についての記録や所管・申し送り事項を書くのに対し、分報はその期間中の好きなタイミング = 短い時間単位で作業の進捗や活動の状況を共有するもの。
分報はSlackなどメッセージサービス等でリアルタイムに共有されるが、このサービスでは分報を書き溜めて任意または一定のタイミングで公開するもの。この仕組みは分報が閲覧者・フォロワーにとってノイズになることを防ぐ目的と記録者（開発者）が分報を書くことに対してハードルを下げることを目的としている。
また、任意の分報を日報に紐づけられる様にすることで、分報を書き溜めることで日報が詳細に記録されたり、思考や作業の過程を日報としてまとめることもできる。
基本的に分報は次のドメインイベントが想定できる。
ドメインイベントは起こった出来事故に過去形で表す。「〜する」はEvent Stormingではコマンドに相当する。
分報を記録した（作成した）
任意の分報を編集した
任意の分報を削除した
任意の分報を即時公開した
任意のタイミングで公開許可のある分報をまとめて公開した
事前に設定したタイミングで公開許可のある分報をまとめて公開した
任意の分報を任意の日報に挿入した
任意の分報を任意の日報から削除する
任意の分報に「ハート」をつけた
ここで「任意のタイミング」とか「公開許可のある」がポリシーになりそう。また、「任意の分報を任意の日報」の集約は分報ではなく日報になりそう。
次の閲覧系をどう扱うかがよくわからなかったのでChatGPTに聞いてみた。
分報リストを閲覧した
分報リストに「ハート」をつけた人をリストアップした
ChatGPT曰くこれらはリードモデル or Viewで表現するのが妥当ぽい。
また、削除みたいに事前に確認して分岐する場合はドメインイベント→許可のポリシー、ドメインイベント→キャンセルのポリシーみたいにするか、確認モデル（Dicision Model）を挟むと良さそう。
モデリングの結果
記録・編集・削除と公開と「任意のタイミングで公開許可のある分報をまとめて公開した」「任意の分報を任意の日報に挿入した」のみとりあえずやってみました。
その他、メモ
Remixのloader側にDMMFを採用するとEvent Stormingによるモデリングが重要になるので学習してみたが、シンプルなドメインイベントだと図にするほどでもない気がする（本当にシンプルかをメンバーで確認や思考整理するとかには良いと思う）。
Event Stormingそのままの表現だけでは当然ながらフロントエンドなのかバックエンドなのかの区別は表現できない。メンバーと認識を合わせるにはそのドメインイベントがフロントエンドまでなのかバックエンドもなのかをワークショップの後に開発メンバー（またはデザイナーも含む）でコンセンサスを取って後で見てもわかるように何かしらで明示化しておく必要がある。
それから、Service BlueprintとEvento Stormingを組み合わせることについて、Event Stormingで言うところのReal Worldやアクター・コマンドがSBと重なる部分だと思う。ESではドメインイベントを最初に列挙するが、そもそもそれが列挙できるのはドメインエキスパートがかなり完全にエキスパートな状態にないと難しく、既存の業務システムや業務フローが完全に定まっているものだとやりやすいが、スタートアップや新規事業のようなドメインエキスパートが曖昧な状態だとドメインイベントを抽出するところが難しいのでは？と感じた。つまり、その前提知識を揃えるというところでシステムがない状態のSBを作り、その後にシステム導入できそうな部分を明らかにした上でESのワークショップをやるのがベターなのでは？と思いました。
Event Stormingの実践動画を見てて思うのは、Real Worldを「システムに関係のない曖昧なものはこれで」みたいにあったけど、デザイナーでもある自分にするとその曖昧な部分が次に必要なサービスや機能であるかもしれないことを考えると、単にシステム化するというだけではもちろんそれでいいと思うけど果たして本当にそれがいいシステムになるのかが懐疑的だし、その部分を事前に明らかにしたり、改めて明らかにするにはService Blueprintや場合によってはユーザストーリーマッピングなど別のもので可視化・ブレストが必要だとより思いました。
そういうところが日本のDXに足らないんだよなーと。