本日の作業
🚴 分報・日報・ユーザに関する設計・実装
✅ Database（Prisma）の実装
🚴 Server側のDomain Eventの実装
サインインの実装
認証画面実装
認証ロジック実装（主にClient側）
Server側の認証チェック実装
Client側の認証チェック実装
🛑 🚴 イベントストーミングとサービスブループリンの融合についてzennにまとめる（次のもくもく会で書く予定）
dbdiagramからPrismaへの変換
dbdiagramのschemaはPrismaぽいのでできるかなーと思って調べてみたらあった…と思ったら逆でした。Prisma Schemaにdbdiagram用のgeneratorを差し込んで変換する。まぁそれはそれであると良いけど設計フェーズでは使えない。
というわけで、自分で書くしかなさそうだけど、よく考えたらChatGPTに投げれば一発で変換できた。便利な世の中だ。こういう仕事ならどんどん奪っていってほしい。
サーバサイドをDMMFで実装する
やっと具体的な実装に入ってきた感があります。Domain Sourcingの話まで脱線というか必要な脱線をしていった結果、Chat GPTがpub/subの話をし始めてしまい思いの外その辺についても学ぶことができました。
というわけで、DMMFをおさらいします（おさらいするほど詳しくはないけども）。
DMMFの原則
DMMF（Domain Model Made Functional）は、関数型プログラミングの原則をドメインモデリングに適用したアプローチ。次のものが主要な原則です。
イミュータビリティ（不変性）
ドメインオブジェクトは作成後にその状態を変更しない。変更が必要な場合は新しいオブジェクトが作成する。
純粋関数
ドメインロジックは純粋関数で表現される。つまり副作用を持たず、同じ入力に対して常に同じ出力を返す。
関数の合成
複雑なドメインロジックは関心事の小さな関数の合成で構築される。
エラーハンドリング
例外ではなくResult型のようにエラーオブジェクトを投げることでエラーを予測可能なものする。
デクララティブプログラミング
デクララティブでロジックをカプセル化して表現する。複数の関心事を直接書かずカプセル化して具体的な処理やロジックは関数の中に収める。
Remix + DMMF
Remixにはloaderとaction/useFetcherがあり、loaderは初期のデータ参照に、actionはWeb標準を意識したRemixのFormコンポーネントからのsubmitをサーバ側で処理するmutationの様なものであり、useFetcherはClient側の非同期でのsubmitでactionへリクエストを送るもの。
なので、主にloader/actionを通じて関数型でドメインモデルを定義・検証し、ドメインイベントを純粋関数で表現し、データ永続層（データベースや外部システム）との連携を行うものと認識しています。
DMMFの原則に従うことでドメインロジックとデータ永続層との間をわかりやすく分離し維持することができます。また、これによりアプリケーションのロジックへの理解や拡張性の向上への足がかりを作っておくことができます。
今回のサービスでは、RemixのServer側をDMMFにし、Client側の主にユーザのインタラクションとの連携部分をOOP型のDDDにしています。
その他、メモ
今日はもくもく会の参加者の方が湘南を離れるとのことでお別れ会食で鎌倉で寿司と鎌倉ディープエリアのバーでした。つまり今日の進捗は少なすし。
