本日の作業
27-28日は体調が悪かったりで、29日は日中は馬術レッスンだったりでここ数日手が全く付けられず作業進捗もほぼない状況でした。反省。というわけで、日付変わりましたが29日分としての日報。
🚴 日報・分報のcommand/event/policyのまとめ書く
✅ command
event
policy
🚴 分報・日報・ユーザに関する設計・実装
✅ 永続層（Prisma）との結合
🚴 プレゼンテーション層（Remix loader/action）との結合
サインインの実装
認証画面実装
認証ロジック実装（主にClient側）
Server側の認証チェック実装
Client側の認証チェック実装
🛑 🚴 イベントストーミングとサービスブループリンの融合についてzennにまとめる（次のもくもく会で書く予定）
日報のcommand関数を実装する
前段としてそもそもcommandとは何ぞやと。
command関数の役割
コマンド関数の主要な役割は、あるドメインイベントを引き起こすためのアクション（ビジネスロジックとデータの永続化など）をカプセル化し、その操作の成功可否を表す結果を返すこと。
これを踏まえてcommand関数の実装をしていきます。
その前に、以前に定義した集約の型定義を結構変更したので載せておきます。尚、値（オブジェクト）や値に相当するサブエンティティは実際は適宜ファイルを分割しています。また、型を生成するにあたってはzodで先に定義してからinferで型に変換しています。値として検証の必要のないものは型のみでそのinferした型にmergeしています。
Commandの定義
以前に定義した日報の記録プロセスから日報の記録 〈RecordDaily〉commandを定義・実装して行きます。
ここで言うcommandの役割はバリデーションした集約を受け取り永続層の状態を変更する純粋関数のことをさします。この関数は全域関数であり、「日報を記録する」と言うcommandは型で表現すると次の通りとなります。
全域関数とは、わかりやすく言えばすべての可能な入力に対して必ず同じ型の結果を返す関数のこと。例えばある入力に対しての成功していればnumber型を返すとします。この時に失敗した結果で例外を返すと関数に対して様々な入力値の一部のみ例外を返してしまうため全域ではなくなってしまいます。尚、この状態を部分関数というそうです。
今回の場合はfp-tsのEither型をどの結果であっても返すということで全域関数の定義を満たしています。
で、その辺を意識して「日報を記録する〈recordDailyReport〉」というcommand関数を実装してみました。中にprismaのコードを直接書いていますが、この辺はDTOできる関数を別に実装して隠蔽しようと思っています。
その他、メモ
本日の馬術レッスン
DDD被害者というワードが一部界隈でバズってるぽい。まぁ色々やりやすいメソッドはあると思いますけど被害者って…なんでそんなセンシティブな言葉にするやら。ちなみに僕はDDDは事業を理解して製品としてアウトプットするための共通言語を持ったメソッドという捉え方をしており、それを最適に進める上で色々アーキテクチャが語られますが、実際興味の範疇としてはアーキテクチャにはなく事業そのものに興味がある人間だしだからこそサービスデザイナーを名乗らせてもらっているのでその辺最適なメソッドが他にあってて言うなら是非そっちをバズらせてほしいお気持ち。
実装量が増えてくると流石にしずかなインターネットにコードを載せるのは厳しくなってきた。とりあえずリポジトリをオープンにすることも検討したいけど、そもそも早くリリースしてとりあえず自分の日報だけでもアプリケーションから見れるようにしないとなーと。
ふと分報がなぜtimesなのか源流を調べてみたらこういう記事出てきた
ChatGPTに聞くと海外には2023年当初の知識ではこういう文化はないぽい。つまりtimesと言う言葉もないので、timesとして概念を持つべきかはちょっと悩ましいところ。
ローカライズでどうにでもなるっちゃなるが、ある種ブランディングにも寄与するので悩ましい。
が、まずそこまで今から考慮するべきでもないってのもわかった上での思考でした。
あと実装の問題で考えると集約名がtimesと複数形なのもちょっと気になる。