本日の作業
🚴 分報・日報・ユーザに関する設計・実装
✅ 日報・分報の公開について修正
🚴 Server側のDMMFの実装
🚴 command/event/policyの型定義と実装
Prismaとの結合
サインインの実装
認証画面実装
認証ロジック実装（主にClient側）
Server側の認証チェック実装
Client側の認証チェック実装
🛑 🚴 イベントストーミングとサービスブループリンの融合についてzennにまとめる（次のもくもく会で書く予定）
日報・分報の公開について修正
上のEvent Stormingだと「下書き or 即時公開」のなのに集約の型定義・zod schemaが次の様に「日報（分報）の公開タイミング」となっていた。正しくはEvent Stormingでよく、予約投稿は今は必要ないので諸々修正しました。
Event Stormingの修正
予約公開など公開タイミング周りが丸っと不要だったのでトルツメ。ついでに公開時の通知周りも再整理して修正done。
引き続き分報も修正する。分報も同じく公開タイミングは不要で下書きと即時公開のみ必要。あと通知周りを整理する。分報公開の度またはメールを飛ばすのはきついし、まとめたタイミングとしても1日に何回かに分けないと分報の意味も薄れるので通知とSlackのみにする。
日報のcommand/event/policyの型定義と実装
集約の型定義・zod schema定義は一旦終わったのでcommand/event/policyの型定義と実装をしていきます。実装の方法は「fp-tsとDMMF」でまとめたのでそれを基に自然言語で具体的な処理などを起こします。これを基に実装を進めます。
日報の記録 〈RecordDaily〉
入力 ─ 日報〈DailySchema〉
日報のタイトル・内容・公開設定を検証する
日報に追加する分報を追加する
出力 ─ Either<Daily>
Slackへの連携済みの場合
Slack APIに投げるデータを生成する
ポストする文
サムネイル
日報詳細のURL
チャンネルの指定
Slack APIへポストする
通知の許可ありの場合
通知サービスへ投げるデータ作成する
通知文
日報詳細のURL
通知サービスへデータを投げる
メールテンプレートを生成する
タイトル
本文
メールを配信キューに登録する
尚、通知周りはどのサービス使うか決めてないので後で実装します。Slackは最初のフェーズでは自分が使えればいいので一旦これも後回し。
その他、メモ
イミュータブルデータモデルとストレージについて
日報の概念をNotionにまとめてますが、イミュータブルデータモデルやDMMFの経ていくうちに、「変更履歴」が日報の概念にもあるのではと。それがどれほどビジネスロジックとして必要かで変更履歴を追える様にするかでイミュータブルデータモデルをどこまでやるかを決めていくのが良さそう。でないと、なんでかんでもドメインイベントを残すとデータベースが本来のサービスに求められる規模感より不必要なストレージを確保しなくてはいけなくなる。
何が言いたいかというと、単なるデータとして考えるのではなくデータベース設計もドメイン知識をそして、そのための考察を繰り返して進めないといけないと思いました。
DMMFについて話した
僕にDMMFのことを教えてくれたエンジニアさんとDMMFやってみた感想などを共有しあった。DMMFが非エンジニアとコードを見ながらコミュニケーションできるのでは？という話になって、処理の流れや処理の命名などがOOPより非エンジニアでもわかりやすいので極論そういうこともできる可能性はあるとか。DDDEUのコント…再現動画ではそれを物語っている。
コードはともかくDMMFの実装は自然言語ととして表現もできるし、図式化もEvent StormingでできるのでOOPよりは確かに非エンジニアにはわかりやすいというのは少しわかる気もする。
とはいえ関数型プログラミング経験がなくDDDも知識だけなどのエンジニアがメンバーに多いとなかなか導入が辛いのではというのも共通認識にとしてあった。というかDDDが難しい、いや事業ドメインへの理解をすることが難しい。ドメインエキスパート不在とか非エンジニアが要求を明確に持っていないとか。そうなるとアプリケーションの設計・実装にも精通していて、ユーザの認知処理やサービス設計にも精通しているデザイナーが最初のブーストの現場にいると良いと思う。ま、そんな人材そうそういないけど。