# 2021-05-19 Pair-A v2 定例

## 疑問
### 粟田
#### リポジトリに定義しても良いメソッド
- 原則は集約ルートオブジェクトの永続化と再構築
- Save(entity)
- Find(entity)
- 他に定義するなら
- 存在チェック
- IsExistId(id)
- リポジトリはIDが使われているかを確認するだけに留める
- 集約内部オブジェクトだけを取得
- ルール違反か？集約ルート単位でSave出来ないようになってればOKな気もする
- こういうケースが生まれ時点で集約を分けることを検討する

#### リポジトリの削除処理の引数に何を渡すか
- 集約ルートオブジェクト
- 集約ルートオブジェクトのID
- その他も許容して良い？例えば名前とか

#### 1つのエンドポイントに対してユースケースは1つになるか
- RestfulなAPIを前提
- GET http://localhost:3000/users
- ユーザー一覧の取得
- GET http://localhost:3000/users?age=20
- ユーザー一覧の取得（絞り込みあり）
- POST http://localhost:3000/teams
- body {name: hoge}
- POST http://localhost:3000/teams
- body {name: hoge}
- 別のユースケースで作っていたら1つのエンドポイントに対して2つのユースケース
- そもそも同じユースケースにしてパラメータで分けるべきか？

#### SPA+APIに時に、どの種類を使うことが多いか
- soap
- REST
- GraphQL
- grpc

#### データベースのカスケード制約をアプリでどう扱うか
- カスケード制約がなくなっても正常に動くようにしておくべき？
- リポジトリのインターフェースとしてはDeleteだけを用意しておいて、実装クラスで使い分ければ良さそう
- RDBじゃなくテキストファイルとかならカスケードがないので自分で実装する必要がある
- RDBでカスケードなら実装しなくて良い（実装クラスはデータベースに依存してしまっても良いのでは？ここは妥協点を探った方が良さそう）
- カスケードを貼らないのもあり
- 別集約に影響する場合は？
- カスケードはっちゃいけなさそう

#### 命名規則について
- 検索
- filter / select
- 絞り込んで複数取得（JSとかC#のLINQ）
- search
- なんか外部APIとか使うイメージ。あんまり使わない
- find
- 絞り込んで1件取得（JSとかRails）
- get
- インスタンスのゲッター以外ではあまり使わないようにしている
- 登録
- create
- 新しく作成する
- register / save
- インスタンスをどこかに保存
- 更新
- update / patch（いまいちっぽい）
- インスタンスをどこかに更新。基本update
- set / changeXXX（言葉が広い）
- インスタンスの状態変更に使う
- 削除
- delete / remove
- 既にあるオブジェクトを削除

英語苦手なのでどう使い分けてるのか知りたい

#### シーク法でページネーションを実装した時の並び替え
- 並び替えに使うキーがユニークじゃなければ実装できなくないか？
- IDを無理やり最後につければ可能か？
- オフセット法じゃなくて基本シーク法を使う？

#### 更新系の処理の作り方
- 更新するプロパティだけでなく、エンティティに必要な情報を全て受け取る場合
- [サンプルコード](https://www.typescriptlang.org/play?#code/MYGwhgzhAECuEFNiQdA3gKGtADrARiAJbDQAWYAdgCYgIAUR1AXNBAC4BORlA5gDTRKYALYJWHbn0Fhe4obBH4EnAJTos2aMAD2lDnBzUw7BNWgBeIQgDu0BJXZF2AT0bVBwsTLmqA3JrYAPRB0JwIODoQzjqcLgB0EGAAbgywRiYI-poAvhh5GKCQMA5OrhrYeIQk2nqSsMDssfSBuNzJmdBMElw8AtCtOO2dXvKSfYKDw6bQsvKUisqcmqpoeTlAA)
- フロントエンドが全ての情報を持つ必要がある
- 本来不要なデータも返すことになる
- 更新するプロパティの情報とIDだけを受け取る場合
- [サンプルコード](https://www.typescriptlang.org/play?#code/MYGwhgzhAECuEFNiQdA3gKGtADrARiAJbDQAWYAdgCYgIAUR1AXNBAC4BORlA5gDTRKYALYJWHbnwCU6LNmgB6RdGAB7Sh1WxOnBJXbQAvND041EIuzWcAngDoAZj2qNq0gNzzs6zYeA6egbGQggA7tD67Fa2boIA5GBhYOxg8YIATAAsnhje2rpR9sAUfAgAcqIMwmK5CtD5ytCAHDaAWb6AaMqNKmYWVjYOEGAAbgwBhQZ10AC+GDMYoJAwUTFy2HiEJKoakrDA1pz0+TjcQymoTBJcPAJHJ2fQAPo14mxXfIK3RKfsqA9gvC9KLARPgEJx5NI0HM1gRiKQAYZnvRpJcpLxVgo9OwdJRoOwyEQIPYnlUvNhobhYZsSlQAZUxPQSWJUdcUZEDCtMPV8YTic8QkyEGTMQhsZxcTyIMKZlMgA)
- ユースケースが複数含まれる
- こっちが有力そう

### 玄徳

#### 不要なコンストラクタは削除すべきか

https://eslint.org/docs/rules/no-useless-constructor

何もしてなかったり`super(...props)`しかしてないコンストラクターは無くてもよいので、消してしまおうというルールがある。
実際、super()しかしてない部分は書いていても読まれないみたいで、テストのカバレッジが下がる。なので消したほうがいいのかなと思ったが、「え！？コンストラクターがない！？」みたいなかんじでパニクったりしないだろうか。自分がそういう文法に慣れてないだけ？

#### プロパティ/メソッド/コンストラクターをどういう順番で書くのか

どういう理由で順番を決めているのか。どういう流派があるのか聞いてみたい。

自分は以下のような順番。

1. プロパティ
2. ゲッタ(セッタ)
3. コンストラクタ
4. メソッド
※ publicなものはprivateなものより先に書く
※ staticなものはそうでないものより先に書く

上から順に読んで「そのクラスが何を表現しているのか」がわかりやすそうな順。呼ばれる側は呼び出す側より後ろにいたほうが読みやすいと思うので、privateメソッドとかはなるべく後ろの方に書きたい。

### 永井
- Nest.jsのコントローラーにおいて、@getの型を型を指定しないせいでeslintに怒られる。どうすればよいのか？
- https://files.slack.com/files-pri/T01G5T3DN5T-F022SV1TPHN/image.png
- テストを優先する層は？
- ドメイン・リポジトリは必須
- コントローラーとユースケースは？
- ドメイン層とフルセットのテストが必須
- テーブルにidがある場合、それはエンティティ？
- ユースケースが別のユースケースに依存するのはありか？
- その場合は横の依存ができてしまう
- リポジトリテスト時に毎回DBが初期化するようにしたい
- からのDb用意して毎回PRISMAでCREATE DELETEする

###### Tags: `Pair-A v2`