# 2021-05-27 第15回メンターセッション

## リポジトリに定義しても良いメソッドについて

- isExistとか、countとかいれてもOKだと思う
- 人によっては「リポジトリはエンティティを返すもの」という過激派もいらっしゃる可能性があり、その場合は怒られるかも

## リポジトリの削除処理の引数について

- 原理主義者はエンティティを渡したがるが、プラハ的にはID渡してもOK！
- 渡す引数を間違う可能性があるような引数は避けると吉

## エンドポイントとユースケースについて

- エンドポイントとユースケースは1対1のものが多い
- 複数のパブリックメソッドがあると凝集度が下がりやすい
- AリポジトリはAメソッドのときにしか使わない、BリポジトリはBメソッドのときにしか使わない←こういうのは凝集度が低い（AとBでクラス分割できる）
***
- GraphQL、アクセスログの扱いとかが難しいなどといった悩みを聞いたことがある
- gRPC、マイクロサービスアーキテクチャのサービス間通信くらいでしか見たことがない

## カスケード制約について
- 基本的に使わないことを推奨
- 物理削除は実際問題あまり使わない（以下参考記事）
https://udidahan.com/2009/09/01/dont-delete-just-dont/
- どうしても許容できないような強力な整合性がある場合以外カスケードを使わない
- DBにロジック入れたくないとはいうが、どこからがロジック？
- RDBの役割「データの整合性を保つ」を全うするための仕組みは、ロジックではない。なので、↓はアリ
- 外部キー制約
- ユニーク制約
- 複合カラムは人によるかも、、、？
- トリガーとかは、あとから見つけにくい
http://soudai1025.blogspot.com/2016/11/rdbantipattern1.html

## 命名規則について
- 強制することはできないので、維持が難しい
- リポジトリはCRUDに近いように
- フレームワークが出しているならそれに従うのが良い
https://vuejs.org/v2/style-guide/
- 何か準拠できるならそれに従うのも良い
- ただし、発言力が強い人に従うべきというのは悪手かも
- 良さそうな記事
https://qiita.com/Ted-HM/items/7dde25dcffae4cdc7923
- マナーとルールは別物！！！！！！！！！！！！！

## シーク法とオフセット法
- データ件数が少ないならオフセットで良い
- シーク法は無限スクロール向き
- ページを大幅に飛ばす場合、キーを探しにくい
- 必ずソートがユニークにならなければだめ

## ユースケースがユースケースに依存

- 避けたい
- より上位概念のなにかを共通に参照するようにしたい（なぜかはうまく説明できない
- テストしやすいから？（モックが増える）
- コードの見通しが悪くなる？
https://little-hands.hatenablog.com/entry/2020/12/22/ddd-in-first-3month

## テストを優先する層

- ドメイン層
- ユースケース層もリポジトリさえモックしてしまえば書きまくれるので書きたい
- 条件分岐が複雑になりやすい
- ドメインサービスが入ってくるならドメインサービスもモックする（どこでコケたかわかりやすくするため）
- 特定のメソッドが呼ばれたか？みたいなテストが多くなりがち
- リポジトリ層はシンプルになりがち
- コントローラー層は書かないことが多いかも（やってることが少ないから）

###### tags: `Team-2`