本日の作業
✅ Remix・FSDでのフロントエンドDDDのアーキテクチャを決める
🚴 Event Stormingについて再度学習
🚴 分報に関する設計・実装
Client側のUseCaseの実装
Domain Eventの実装
Database（Prisma）の設計・実装
Supabaseの設定と開通
Supabase Auth
Supabase Database
🛑 🚴 イベントストーミングとサービスブループリンの融合についてzennにまとめる（休日にやる）
Remix・Feature Sliced Design（FDS）におけるアーキテクチャ
Remixの制約
routesに生やせるloaderはServer Sideのイベント（loader/actionはServer Side向けのイベント関数である）であるのでroutes以外のコンポーネントでは使えない。
loaderはイニシャルレンダリングでのデータフェッチとactionによるmutationでのServerを介したリレンダリング。
ユーザインタラクションをリアルタイムでバリデーションする場合はaction/loaderではやり方次第ではできなくなさそうだが、リクエストが頻発してしまうので素直にClient Sideでやった方が良い。
actionは基本的にはWeb標準に準拠しているのでForm要素のsubmitでトリガーされる
FSDの制約
次の日報の「FSDとRemixのloaderの関連について」にまとめた
アーキテクチャ案
前提として次の様にする。
Server Side
loader/actionはBFFであるとして、ここではDMMFを採用する。
型ベースの値の検証（バリデーション）にとどめる
集約のドキュメント性などよりドメインイベントに重きを置いてDatabaseや外部システムとの連携をわかりやすくする
Client Side
Client SideではFront EndであるのでOOP型のDDDを採用し、Repository PatternでViewとの連携を図る
ユーザインタラクションをリアルタイム検証（バリデーション）することに注力する
ドメイン及びアプリケーション（主にView）の状態管理と連携する
Gateway/Fasade/Adapterの類は基本的には設けず（Client Sideでのみ必要な場合〈リアルタイム検索などの内部APIや外部API・Local Storageなど〉は設ける）、Remixのactionを通しBackend側でドメインイベント経由で永続化や外部システムのfetchを行い結果をloaderで取得する
loaderで取得したデータをUseCase HooksでRepositoryを介して集約インスタンスにしそれを状態として持たせる様にする
その他、メモ
Remixのloader側にDMMFを採用するとEvent Stormingによるモデリングが重要になるのであらためて学習というかEvent Stormingを実践して見る方が良さそう。