## 認証について
- 結論：
- 今回の要件であれば（ユーザーテーブルは）不要かも
- でもユーザーテーブルはつくることも多い（一番の理由は拡張性）
- ただしその場合もfirebaseのユーザー情報を持っているテーブルを複製するのではなく、firebaseのuidをカラムに持つuserテーブルを作るイメージ
- 認証サービスを乗り換える可能性もあるため
- またパスワードをサービス内に持ちたくないため

---

- ユーザテーブルがないと）ユーザがpostとかquestionみたいなリソースを作るときに外部キー制約が貼れない⇨userIdを使って外部キー制約を頻繁に設定する必要があればつくるなど（？）

- 認証手順）front->firebaseを叩いてトークン取得⇨idtokenをバックエンドに送る

- firebase uiというサービスもある

## リポジトリの実装クラスで使用する、DBから取得したオブジェクトを再構成するメソッドとバリデーションについて
### 質問
（エンティティは不完全な状態のインスタンスを作成しないようにする、ということを前提とした話です。）
リポジトリの実装クラスで、DBから取得したオブジェクトからバリデーションなしでインスタンス生成（再構成）するようにしたい場合、エンティティに専用のコンストラクタまたはメソッドを定義するパターンがあるようです。
参考: ログラス松岡さんのQ&A https://github.com/little-hands/ddd-q-and-a/issues/277

// イメージ
class User {
  private constructor(private name: string | nameValueObject) {}

  // 作成用のメソッド
  static create(name: nameValueObject): User {
    // ここでバリデーション？
    return new User(name)
  }
  
  // 再構成用のメソッド
  static reconstruct(name: string): User {
    return new User(name)
  }
} 

このパターンを実現する場合、エンティティのバリデーションはコンストラクタではなく、全て作成用メソッドのcreate内でやるべきなのでしょうか？
実装のイメージ（あと、再構成メソッドが役に立つケースも…）が湧かなかったため、もし知見をお持ちでしたらご教示いただきたいです！

### 回答
- reconstructが欲しくなるケース
- エンティティのインスタンス生成時に、外部のWeb APIを叩くバリデーションやプロパティに初期値を設定している
- DBから取得したオブジェクトに対してもそれをやるのは無駄なので、別の方法でインスタンスを生成したい

- （追加で質問）publicなコンストラクタを2つ（create用・reconstruct用）作るのはどうか？
- コンストラクタをファクトリメソッドに置き換えるようなリファクタリングをする場合、やりづらい（エディタの置換などではできない）
- 最初からファクトリメソッドを作っておいた方が良い
- コンストラクタ含め、引数のユニオン型、オプショナルはなるべく避ける。分岐が増えて、バグが入り込む恐れがあるため。

- バリデーションが変わったとき
- 例）nameの上限が100字から50字になった
- バリデーション変更前にDBに入ったデータも、50字が上限になるようにマイグレーションするのでは？
- DBに入っている50字を超えたデータは許容することもありそう

###### tags: メンターセッション