リポジトリパターン

ドメインオブジェクトの永続化と再構築を担うパターン。

なんらかのデータストアと直接やりとりする。

class Program
{
  private IUserRepository userReopsitory;
 
  public Program(IUserRepository userRepository){
    this.userRepository = userRepository;
  }
 
  public void CreateUser(string userName){
    var user = new User(new UserName(userName));
    var userService = new UserService(userRepository);
 
    if (userService.Exists(user)) {  // Existsは実際の重複チェックをリポジトリ経由で行う
      throw new Exception();
    }
 
    userRepository.Save(user); // どこのデータストアに保存されるかに関心を持たない
  }
}

• ※ Existsをリポジトリに実装するのはNG？
  • NG。リポジトリの責務である「永続化」の範疇を超えているため。
  • 重複チェックはドメインルールに近いので、ドメインサービスが行うべき。

リポジトリの実装

• Interfaceを用意し、Find, Saveなどのメソッドを定義する
  • ユースケースが特定のインフラに依存しないようにするため、抽象型を使う
    • SQLRepository
    • InMemoryRepository(テスト用)
    • ORMRepository　など

public interface IUserRepository
{
  void Save(User user);
  User Find(UserName name)
}

• 永続化に関するふるまいを定義（メソッド名は任意）
  • Save(Entity)
    • 個別のフィールドのUpdateは実装しない。updateName, updateEmail…と膨らんでいくため
    • そういった変更のふるまいはエンティティにもたせる
  • Delete(Entity)
• 再構築に関するふるまいを定義（メソッド名は任意）
  • Find(Identity)
  • FindAll()
  • FindByHoge(Fuga)（特定の探索に特化）
    • 可能なら、Findをオーバーロードする手段もある