本日の作業
🚴 分報・日報・ユーザに関する設計・実装
🚴 Server側のDMMFの実装
✅ interface, zod schema
command & event
Prismaとの結合
サインインの実装
認証画面実装
認証ロジック実装（主にClient側）
Server側の認証チェック実装
Client側の認証チェック実装
🛑 🚴 イベントストーミングとサービスブループリンの融合についてzennにまとめる（次のもくもく会で書く予定）
日報・分報の集約を定義・実装
DMMFでの日報・分報の集約を定義・実装です。やっとここまできました。
日報の集約
Daily型が集約の本体ですが、commandやdomain eventなど入力・出力でzod schemaを定義する際にコアになる部分はほぼ同じなのでzod schemaも定義しています。尚、異なる場合はomitやpickで専用のschemaにしていきます。
また、contentsSchema, publishSchema, titleSchameは現在のところ日報集約の値オブジェクトとして別途定義しファイルを切り出しています。
一つ挙げると、例えば日報の公開に関する値オブジェクトは次の様にしています。
分報の集約
Times（分報）の集約です。コンテンツと公開範囲・タイミングを値として持っています。ここで公開の定義は範囲が加わっています。日報にも公開範囲が必要な気がしていますがこの辺は後で精査します。
型定義・schema定義というか、ドメイン層は基本後でリファクタで見直しが入って当然なものなのでここで無理に完璧にする必要はないと思っています。
その他、メモ
仕事でCloudflareでドメイン取得しよう思い触ってて気づいたけど、Cloudflareはよくある最初のアカウント登録後にワークスペースを作って必要であれば別のワークスペースを作る…みたいなことができなかった。
個人用でアカウントは持っていたけど、仕事用と切り分けたいなと思うとこういう感じで構成されているので別アカウントを作る必要があった。
これの何が問題かというと、一つのメールアドレスで複数のアカウントを作れない…。よくやる `[email protected]` みたいなことも厳格にバリデーションされていてできず、しかも仕事の方がドメインも持っていない（そもそもCloudflareでドメイン取ろうと思っていたので）ため、メールアドレスもないのでやむを得ずそれ専用にGmailを作成してCloudflareのアカウントを作成するということになってしまった。
急いでいたのでもしかしたら何か手段があるのかもしれないけど罠すぎる。そして不要なGmailを作成して管理があちこち分散されてしまうの辛い😇
前に仕事でワークスペースの設計をしたことある。この時もそもそも最初にワークスペース制を導入していなかったがユーザのメンタルモデルやドメインモデルや振る舞いの整理の中からワークスペースにした方が明らかに管理・登録における効率やユーザビリティの面で良いと判断してそうなった。Cloudflareは色々良いのだけど、ところどころ「んー…」と思うところが多くて。中のデザイナー頑張れって思うけどデザイナーいるのかな？流石にいるよね？