本日の作業
🚴 分報に関する設計・実装
✅ Client側のUseCaseの実装
🚴 Server側のDomain Eventの実装
Database（Prisma）の設計・実装
Supabaseの設定と開通
Supabase Auth
Supabase Database
🛑 🚴 イベントストーミングとサービスブループリンの融合についてzennにまとめる（休日にやる）
OOP型 DDDのUseCaseについて
Repository, 集約, 値オブジェクトについては以前まとめてます。
UseCaseの役割と仕組み
UseCaseはRemix上にあるFeature Slice DesignのEntititesレイヤーのコンポーネントのインタラクションと各ユースケース毎にRepositoryを仲介する役割を持ちます。
UseCaseは今回はクラスや独立した関数してHooksがインスタンスを生成する方法ではなく次のことからReactのHooksにしました。
Hooksでインスタンスを生成するだけでコード分割している様なものだったのでHooksに直接おく方がコードのインデックス性が高まるため
今回はClientはOOP DDD with Repository PatternでRemix（React）以外 = ユーザのインタラクションとインターフェイス以外からはインスタンスを呼ぶシーンが想定できないため
UseCaseというよりRepositoryを生成し各種UseCase相当の子HooksをインデックスするルートHooksという構成です。
ルートHooks内でRepositoryのインスタンスを生成します。必要に応じてGateway（FasadeとかDTO的なもの, APIや外部システムとの連携と変換装置）をDI（Dependency injection）します。
こうすることで、Component上にuseUseCaseを置いて返り値にある各子UseCase関数を必要な時に呼べばRepositoryを通じて集約を変更したりしつつUseCase生成時に渡すGateway（APIを通じてDatabaseなどで永続化したり、外部システムへのリクエスト・レスポンスを受け取るもの）で永続化やデータの呼び出しができる仕組みです。
尚、今回はRemixのloader/action関数上（Server上）でPrisma ORMを通じてDatabaseへの永続化などを行います。
各種実装
UseCaseRootHooksとUseCaseFunction型
ユースケースに関係する関数の型定義（ジェネリクス）を先にしておきます。これらを使ってUseCaseのルートHooks（UseCaseRootHooks型）や子Hooks（UseCaseFunction型）にキャストしていきます。
UseCaseの子Hooks
具体的なUseCase関数の実装です。例としてメールリンク認証時のメールアドレスを入力するユースケースを実装しています。
UseCaseのルート（親）の実装
さっき実装したinputMaillinkAddressなど関係する子Hooksをインデックスするのと、Repositoryインスタンスを生成してそれらにDIしています。
その他、メモ
仕事の方が忙しい。自走型でグイグイ来るエンジニアさんになかなか出会えない。勉強会で出会うエンジニアや会社員時代のエンジニアはグイグイ来る人多かったけど、仕事で出会う人でグイグイ来る人に滅多に出会えない。そんなもんなんだろうか？
確定申告98%くらい終わらせたが、途中30円数が合わないという昭和の経理みたいなことになって数時間失ってしまった。理由は単にクライアントが間違えて30円多く支払っていたためでした。freeeの自動経理は数字が違うと作動しないし、なんなら毎月同じ金額とかのものだとズレて自動経理していたりする。しかも帳簿ではそれが気づけず口座を見て気づいたのでなかなか罪深い。
freeeは古の経理ソフトに比べれば使いやすさはだいぶ増しているとは思うけど、画面を見るとどうにも機能駆動で作られていて、ドメインモデルやユーザのメンタルモデルに沿っていない様に見える。まぁでもあの規模を今からこれらを考慮して見直してリビルドするのはもっと辛いだろうから中の人たち頑張れとしか思わない。