[도메인주도설계철저입문] 5장 리포지토리

도메인 주도 설계 철저 입문 5장 학습 내용을 정리 한다. 

도메인 주도 설계 철저 입문 - 예스24

 

리포지토리란?

소프트웨어 개발에서 말하는 리포지토리는 데이터 보관창고를 의미한다. 데이터를 저장하고 복원(조회)하는 처리를 추상화하는 객체이다. 객체 인스턴스를 저장할 때는 데이터스토어에 기록하는 처리를 직접 실행하는 대신 리포지토리에 객체의 저장을 맡기면 된다. 또 저장해 둔 데이터에서 다시 객체를 조회할 때도 리포지토리에 객체의 복원을 맡긴다. 이런 방법으로 리포지토리를 거쳐 간접적으로 데이터를 저장 및 복원하는 방식을 취하면 소프트웨어의 유연성이 향상된다. 

리포지토리의 책임

리포지토리의 책임은 도메인 객체를 저장하고 복원하는 퍼시스턴시다. 퍼시스턴시라고 하면 무조건 관계형 데이터베이스를 떠올리는 사람이 많지만 데이터베이스만을 또는 특정 제품만을 의미하는 것은 아니다. 

class Program 
{
  public void CreateUser(string userName)
  {
    var user = new User(
      new UserName(userName)
    );
    
    var userService = new UserService();
    if (userService.Exists(user))
    {
      throw new Exception($"{userName}은 이미 존재하는 사용자명 입니다.");
    }
    
    // DB 접속 및 Insert 코드
    var connectString = 
      ConfigurationManager.ConnectionString["DefaultConnection"].ConnectionString;
    using (var connection = new SqlConnection(connectionString))
    using (var command = connection.CreateCommand())
    {
      connection.Open();
      command.CommandText = "INSERT INTO users (id, name) VALUES (@id, @name)";
      command.Parameters.Add(new SqlParameter("@id", user.Id.Value));
      command.Parameters.Add(new SqlParameter("@name", user.Name.Value));
      command.ExecuteNonQuery();
    }
  }
}

Repository 패턴을 적용하면 경우 아래와 같이 사용될 수 있다. DB 연결, 쿼리 등을 Repository 구현체로 넘길 수 있다. 

class Program 
{
  private readonly IUserRepository _userRepository;
  
  public Program(IUserRepository userRepository)
  {
  	this._userRepository = userRepository;
  }
  
  public void CreateUser(string userName)
  {
    var user = new User(
      new UserName(userName)
    );
    
    var userService = new UserService();
    if (userService.Exists(user))
    {
      throw new Exception($"{userName}은 이미 존재하는 사용자명 입니다.");
    }
    
    // DB 접속 및 Insert 코드
    _userRepository.Save(user);
  }
}

IUserRepository 인터페이스나 구현체의 구체적인 소스는 여기서 중요한 내용이 아니라고 생각되어 생략한다.

객체의 저장과 관계된 행위 시 팁

 - Save 또는 Store와 같은 네이밍을 보통 사용할 수 있다. 
- 저장 대상 객체를 인자로 전달받아야 한다. ( 속성으로 전달 받지 말고, 객체 자체를 인자로 전달 받아야 함 ) 
- 객체가 저장하고 있는 데이터를 수정하려면 애초부터 객체 자신에게 맡기는 것이 옳다. ( 도메인 객체의 행위로 인해 값이 변경되어 있어야 함 ) 

고민되는 부분

- Repository의 Create, Update, Delete(Soft) 메서드
   -> 1. Upsert와 같은 Save메서드로 통합 한다.
   -> 2. CUD에 대한 각각의  메서드를 정의 한다.
 - Repository를 애그리게이트 단위로 생성한다. vs 하위 도메인에서 Repository를 생성 한다.
 - 도메인 객체의 속성들의 변경주기가 다른 경우 
   -> 1. Save 메서드로 통합 한다.
   -> 2. 각각의 메서드로 정의 한다. 

정리 

로직이 특정한 인프라스트럭처 기술에 의존하면 소프트웨어가 경직되는 현상이 일어난다. 코드의 대부분이 데이터스토어를 직접 다루는 내용으로 오염되며 코드의 의도가 잘 드러나지 않게 된다. 

리포지토리를 이용하면 데이터 퍼시스턴시와 관련된 처리를 추상화할 수 있다. 이 정도의 변화만으로도 소프트웨어의 유연성을 향상시킬 수 있다.
예를 들면 초반에 인메모리 DB를 사용하다가 MySql로 변경을 하더라도 Service 레이어에 영향을 주지 않게 된다. 서비스 레이어를 테스트할 때도 의존성이 분리되어 있기 때문에 서비스레이어를 테스트하기 쉬워진다. 쿼리 성능을 올리기 위해 쿼리 방법을 변경하더라도 서비스레이어에 영향을 주지 않는다.