# 2022/08/31

## 各タスク進捗
- kubota
- バックエンドのディレクトリ作成のPR レビュー依頼中
- この後DBとかPrisma導入のPRが控えていて、変更大きくなるとレビューしづらくなると思うので、早めにマージできると嬉しいです！
- DB, Prisma導入のPR作成中
- GitHubのbranch protection（デフォルトブランチへのpush防止等）は無課金だとできなかった😢
- せっかくリポジトリ移譲してもらってGitHubとSlackしたのに、通知がうまく行ってないぽくて困惑している...

## 話したいこと
- ドメイン関連）
1. タグの追加・編集・削除について by Mirai：済み
- 現行のヒアリング結果では、タグ追加は全員が行えて、編集や削除は管理社員のみが行える
- タグの存在意義は、質問の整理や検索を便利に行うためだと思うが・・・
- もし投稿者が把握していないところで、管理者がタグの削除や編集を行なっていたら、投稿者は混乱しないか？
- 自分で設定したタグが消えていたり、名前が変わっていたら、バグだと思わないか？
- それを防止するには、タグが編集されたり削除されたら、タグを使用していた人に変更を通知するのがシステムとして当たり前の気遣いではないか？
- そんなタグが現実に存在するのか？
- 思うに「タグ」という概念は「質問の整理・検索性能を上げたい」の具象化であって、POが言うタグの在り方はシステムとしてセオリーから外れてはいないか？
- 参考その１）Yahoo知恵袋のタグ機能は、自分で付与したり削除できない（質問のキーワードなどから自動で最大７つ付与される）
- 参考その２）ブログの投稿などを整理するためのタグ機能、ECサイトなどのタグ機能は、オーナーしか追加編集できない
- POに提案したいこと）タグの追加・削除・編集は管理社員だけが行えるようにすべき。

2. 投稿の編集・削除について by Mirai：済み
- 「タグの追加・編集・削除について」と同じ理由で、管理社員が一般社員の投稿を編集・削除する場合は、何らかの通知を行なってあげた方が親切だと思う
- 投稿を編集・削除したい意図はなにか。
- 質問の見栄えや体裁を整える理由があるのか？
- YESの場合）ただのQAサービスではなくその回答を資産化してWikiを作りたいのかな？という意図が想像できる
- NOの場合）普通のQAサービスで回答は資産化する必要がなさそう。であれば管理社員に編集機能も削除機能もいらないのでは・・・
- POに確認したいこと）管理社員が一般社員の投稿を編集・削除したい理由を聞いて、実際のニーズは何なのかもう少し深掘りたい。

3. ドメインモデル図・ER図について by Mirai：済み
- まだ情報が少ないので揉むのは難しいですが・・・
- 投稿に対して回答がついて、さらにスレッド式に投稿者が回答者へ、お礼を伝えたりまだわからないことを追加質問していくことは想像に難くない
- モデルに落としたい

- バックエンド関連）
1. 僕の希望でNest.jsのコアをFastifyにしてもらった件について by Mirai：
- Fastifyのメリットは、TS と async/await がデフォルトサポートされている点
- でもドキュメント読んだ感じだと、Nest.jsはExpressコア、Fastifyコアどちらでも、TSと async/await は組み込まれていた（すみません）
- 強いて言えばFastifyの方がパフォーマンスは2倍くらいらしいのでそのままでもOK
- ただサブドメインルーティングはFastifyコアで利用できないらしい（https://docs.nestjs.com/controllers#sub-domain-routing）
- サブドメインからのリクエストであることを検証したい場面はありそうか？
- もしあればデフォルトのExpressコアに戻した方がいいかもしれない（土下座）
2. superクラスを作るか（値オブジェクトなど）決める。
- 値オブジェクト(OK)
- エンティティ
- 集約ルート
- ユースケース
- コントローラ
4. usecaseのパブリックメソッド名を決めたい（call, run, do, execute...）。
- do (一番短い)
5. CQRS, CQS どうする
- CQRS
- DB分けるまでは実施しない
- CQS
- 必要になったら導入してみよう！
6. テストどこまで書くか決める。
- 不要
- コントローラのUT
- レポジトリのUT
- 必要
- レポジトリのIT
7. path エイリアス
- 試してみるが、ハマったら諦める
- フロントエンド関連）
1. レビューでいただいた案について by Mirai： prefixなし
- TailwindCSSのクラス指定時、`tw-` のprefixをつけるのはどう？というご提案をいただきました！
- 僕はどちらでもいいので、皆さん意見があればお願いします。
- メリット：仮にCSSModuleなど利用することになっても、TailwindCSSのクラス名とそれ以外の見分けがつくようになる
- デメリット：記述がやや冗長になる

ドキュメント作成チーム（kaizuka, tomita, kondo）は次のPOヒアリングまで作業ないので、バックエンド or フロントエンドのタスクに着手する

###### tags: `チーム定例`