レイヤーの種類

• handler
• usecase
• service
• repository

handler

記載するもの

• 認証
  • 認証情報があるか
  • その認証情報が正しいか
    • 認証ユーザの特定までは行う
      • この場合DBにアクセスが必要
      • ビジネスロジックでないDBアクセスが発生する
      • 認証のユーザ特定のためのユースケースを設置する
  • 権限のチェックはしない
• バリデーション
  • 対象
    • パスパラメータ（URLに埋め込まれたパラメータ）
    • クエリパラメータ（URLに付加されたパラメータ）
    • Bodyパラメータ（bodyに埋め込まれたパラメータ）
  • ビジネスロジックを含まないインターフェースのバリデーションを行う
    • プロパティの存在チェック
    • 値のNULLチェック
    • 値の型チェック
      • 日付文字列の場合、正常に日付型に変換できる値であるかのチェックはここの責務とする
  • openapiなどで定義をしている場合はその定義に沿ったvalidationを実行
    • require: 項目が存在するか
    • null: 項目がnullか
    • type: 項目の型式（数値、文字、真偽、型式、オブジェクト、日付型、メールアドレスなど）
    • length: minとmaxの長さ、空文字不可の場合はmin1文字にする
    • range: min、maxの大きさ
• ユースケースの実行に必要なパラメータの組み立て
• ユースケースの実行
• ユースケースの戻り値からレスポンス用パラメータの組み立て
• レスポンスの返却

usecase

アクターからの操作を表す
そのため、名称は 人 + 動作 + 対象 となる
例） 教師が授業を登録する -> TeacherRegistSubject

記載するもの

• 認可
  • 権限チェック
    • 操作者が定められているアクターの要件を満たしているかをチェックする
• バリデーション
  • usecase特有のバリデーション
    • ビジネスロジックのバリデーションと区別をつけるのが難しい
    • ただし、ここで行うものとビジネスロジックで行うものとは違いが存在する
    • 例
      • 「記事を投稿する」というユースケースに対して、「投稿日」と「投稿予約日」というパラメータが存在するケースを考える
      • 「投稿日」は投稿された現在日時そのものとなる
      • 「投稿予約日」は「予約」であることから、「投稿日」より未来、かつ、現在日時より未来であることが要件として想定される
      • では、このバリデーションはユースケースに記載するべきか
      • 「投稿日」が現在日時であること、「投稿予約日」が「現在日時より未来であること」はユースケースで実施
        • 現在日時がカラムチェックについてはおうおうにして、あるユースケースを想定した場合のケースが多い。この場合も同様で、うっかり違う日時で登録して無効なデータを作り出さないためのチェックである
      • 「投稿予約日」が「投稿日」より未来であることはビジネスロジックで実施
        • 「投稿予約日」>「投稿日」はデータとして許さない（実際にありえない）チェックであり、これはこのデータの普遍の真理である
        • そのため、こういったチェックについてはビジネスロジック側で実施する必要がある
    • このケースを考えた場合、ユースケースには現実の日時についても含有するということが言える
• データの取得処理のみの場合は複数リポジトリの実行を許容する
  • レスポンスを返却するために取得処理しか行わない場合、単数、複数にかかわらずユースケース内での実行を許容する
  • ただし、シンプルであっても、追加、更新、削除の操作についてはこれを許容しない
    • ビジネスロジックのバリデーションが発生することが想定されるため
• その他の場合、serviceの実行を行うものとする

service

各処理の実質的な入口となる
名称としては 動作 + 対象 となる
例) 授業を登録する -> RegistSubject

記載するもの

• バリデーション
  • serviceに適用可能なバリデーションはビジネスロジックのバリデーション
  • ありえないデータのバリデーションはここで実行される
• ビジネスロジック