리포지토리 _ '도메인 주도 설계 철저 입문' 정리

* 이 글은 책을 읽고 주관적인 생각과 함께 요약 정리한 글입니다. 설명을 위한 글이 아니므로 내용이 정확하지 않을 수 있습니다. 

 

 

 

제목 : 도메인 주도 설계 철저 입문

저자 : 나루세 마사노부

범위 : 리포지토리

 

 

---

 

리포지토리

• 리포지토리의 책임은 도메인 객체를 저장하고 복원하는 퍼시스턴시(영속성 - 지속됨을 뜻함)다.
• 리포지토리에 정의되는 행위는 객체의 저장 및 복원에 대한 것이다.
  • 행위 예시 : save, add, get, store, update, find, find_all, delete

 

리포지토리를 사용하는 이유

• 비즈니스 로직이 기술적 요소와 깊은 관계를 맺으면 자칫 문제 해결을 위한 코드가 기술 코드에 침식 당하기 때문에 의도를 파악하기 어려워진다.
  • 로직이 인프라스트럭쳐 기술에 의존하면 소프트웨어가 경직된다.
  • 리포지토리는 이런 기술을 따로 분리해 비즈니스 로직을 순수하게 유지시킨다.
  • 비즈니스 로직과 코드의 의도가 명확해진다.

 

• 리포지토리는 데이터 퍼시스턴시와 관련된 처리를 추상화하며, 이것만으로 소프트웨어의 유연성이 놀랄만큼 향상된다.
  • 데이터 스토어를 교체하기도 쉽고, 테스트도 쉽게 수행할 수 있다.
  • 어떤 데이터 스토어를 사용하는지는 이제 사소한 문제일 뿐

 

인터페이스

• 리포지토리는 인터페이스로 정의된다.
• 리포지토리의 책임은 객체의 퍼시스턴시까지다. 즉, 도메인 규칙과 관련된 항목은 서비스에서 다루는 것이 옳다. (예시 : 이메일 중복확인)
• 인터페이스에서 나중에 사용할 메서드를 미리 만들지 말자. 현시점에서 필요한 최소한의 정의만 작성하자.

 

리포지토리 구현

• 비즈니스 로직에서 특정한 기술에 의존하는 구현은 바람직하지 않지만, 리포지토리의 구현 클래스라면 특정 기술에 의존하는 구현도 문제가 없다.
• 객체를 저장하려면 저장 대상 객체를 인자로 전달 받아야 한다.
  • 객체의 식별자(id)나 수정 항목을 인자로 받도록 메서드를 정의하면 안됨.
  • 만약 이렇게 하면 불필요하게 많은 수정 메서드들을 정의해야한다.
  • 객체가 저장하고 있는 데이터를 수정하려면 객체 자신에게 맡기는 것이 옳다.

 

• 객체를 생성하는 처리는 리포지토리에 정의해서는 안 된다. → 9장 참조
• 객체를 파기하는 메서드는 리포지토리에 정의한다.
• 객체 복원(조회) 메서드는 보통 식별자를 사용한다.
  • 만약 객체의 존재여부를 확인해야 한다면 인자에 검색키를 추가하여 전체 객체를 조회하지 않도록 구현하자. (오버로딩으로 구현해도 ok)

 

궁금한 점

• 서비스에서 리포지토리로 바로 가지 않고 인터페이스를 거치는 이유는 무엇인가?
  • 서비스와 리포지토리 간 결합도를 낮추기 위함.

 

기타 알아두면 좋을 것

• Option타입은 ‘있을 수도, 없을 수도’를 의미하므로 Null 반환에 대한 힌트를 제공하지 않아도 됨.
• 테스트를 위해 메모리를 데이터스토어로 삼자. 이렇게 하면 테스트 시 데이터스토어에 대한 의존이 줄어든다.