Repository Pattern (리포지토리 패턴)

비즈니스 로직이란?

일반적으로 데이터베이스와 UI 사이에서 정보 교환을 처리하는 알고리즘을 설명하는데 사용하는 비기술적 용어 또는 업무에 필요한 데이터 처리를 수행하는 응용 프로그램의 일부를 의미하며, 데이터 입력, 수정, 조회 및 보고서 처리 등을 수행하는 루틴으로 생각할 수 있습니다.

 

예를들어, 회원가입 시 아이디 중복 확인하기 -> 회원 정보가 저장된 DB에 접근 -> DB에 중복되는 ID가 있는지 검색 -> ID 중복 여부에 따른 처리 -> DB 연결 종료 -> View 데이터 전달

 

이런 동작 또는 행위를 비즈니스 로직이라고 생각하면 됩니다. 비즈니스 로직을 얼마나 잘작성하냐에 따라 유지보수와 확장성 등에 영향을 주며, 이런 점에서 좋은 품질인지를 파악할 수 있겠죠. 

 

리포지토리 패턴이 탄생하게된 것은, 위에서 말한 비즈니스 로직을 잘작성하기 위해서 탄생했습니다. DB나 웹 서비스 등의 데이터 저장소에 접근할 때 중복되는 코드 또는 오류를 발생시킬 수 있는 코드 등으로 인해 비즈니스 로직과 데이터 레이어를 분리하고 중앙 집중 처리 방식으로 일관성있는 데이터를 유지할 수 있도록 하기위해서라고 합니다.

 

Repository는 데이터 소스 레이어와 비즈니스 레이어 사이를 중재하며, 데이터 소스에 쿼리를 날리거나, 데이터를 다른 domain에서 사용할 수 있도록 새롭게 mapping 할 수 있다고 합니다.

 

즉, 리포지토리 패턴은

데이터가 있는 여러 저장소를 추상화하여 중앙 집중 처리 방식을 구현할 수 있고, 데이터의 출저가 다르더라도 리포지토리를 참조하여 리포지토리가 제공하는 데이터를 이용할 수 있습니다.

 

결과적으로 무엇이 장점일까?

제가 생각해보았을땐 추상화라는 개념이 있는 것으로 보아, 확장성의 이점과 중복되는 코드를 줄일 수 있다? 정도만 생각이 들었습니다.

 

리포지토리 패턴의 장점

1. 데이터 로직과 비즈니스 로직을 분리시킬 수 있습니다.

2. 중앙 집중 처리방식으로, 일관된 인터페이스로 데이터를 요청할 수 있습니다.

3. 단위 테스트를 통한 검증이 가능합니다.

5. 객체 간의 결합도를 감소시킬 수 있습니다.

 

이러한 장점이 있다고 합니다. 아직 단위 테스트를 경험해본 적이 없는데, 무엇을 배우든 단위 테스트의 이점이 항상 있는 것을 보니, 7월이 되기전에 한번 공부해봐야겠다고 느끼게 되네요!

 

리포지토리 패턴을 공부하게 된 계기가 클린 아키텍처를 공부하면서 꼭 필요하다고 느껴서 공부를 하게되었는데, 예제 코드들도 모두 제각각이고 구현 방식도 다르고, 공통점을 찾아보면서 이해하려고 해봤지만, 쉽지가 않았습니다ㅠㅜㅠㅜ 3일간 여러 코드를 보고 공부하면서 대체 이게 뭐지? 라는 생각 뿐이었습니다.

 

Repository, domain model, data Source, Dao 등 여러 개념들이 등장하여 하나씩 천천히 정리해보며, 완전히 이해해보도록 하겠습니다.

 

Domain Model

행동과 데이터를 통합하는 도메인의 객체 모델 또는 소프트웨어로 해결하고자하는 문제 영역을 표현한 것입니다.

 

1. Entity : 고유의 식별자를 갖는 객체로, 자신의 라이프 사이클을 가지며, "주문, 회원, 상품" 등과 같이 도메인의 고유한 개념을 표현합니다. 도메인 모델의 데이터를 포함하고 해당 데이터와 관련된 기능을 함께 제공합니다.

2. Value Object : 고유의 식별자를 갖지 않는 객체로, 주로 개념적으로 하나인 도메인 객체의 속성을 표현할 때 사용됩니다. 구매 금액을 의미하는 "금액"을 Value 타입이라고 보면 됩니다. Entity의 속성으로 사용되면서, 다른 Value 타입의 속성으로도 사용될 수 있습니다.

3. Aggregate root (DDD only) : 관련된 Entity와 Value 객체를 개념적으로 하나로 묶어둔 것으로, 예를들어 "주문"과 관련된 Entity와 Value 객체를 "주문" 애그리거트로 묶을 수 있습니다. 

 

단순한 도메인에서 이러한 모델은 데이터베이스 및 네트워크 모델(DTO)와 유사해보이지만 차이점이 많다고 합니다.

 

도메인 모델은 데이터와 프로세스를 혼합하며, 구조가 앱에 아주 적합하지만,

DTO는 JSON / XML 요청, 응답 또는 데이터베이스 테이블의 개체 모델 표현이므로 해당 구조는 원격 통신에 적합합니다. 추가로 DTO는 Gson, Room 프레임워크에 따라 서로 분리해 각각 작성합니다.

 

Data Mapper

이곳에선 DTO를 Domain Model에 매핑하거나, 반대로 매핑합니다.

Data Source부터 UI까지 데이터를 처리하는 과정에서 Mapper를 사용하지 않게되면, Data의 스팩이 달라질 경우 Presentation layer에 존재하는 Activity, Fragment, VM 등에서 문제가 발생하기 때문에 Mapper를 사용해주는 것이 좋다고 합니다. (해당 부분은, 예제를 통해 이해하면 다시 정리해보겠습니다.)

 

Data Source에 대한 DTO를 사용하는 프레임워크에 따라 각각 만들어줘야하는 이유

만약 하나의 DTO를 생성하고, 이것으로 네트워크와 DB 모두에서 사용하게되면, 문제점이 발생한다고 합니다.

1. 필요 이상으로 캐시할 수 있습니다. (???)

2. Field를 추가하려면, 데이터베이스 마이그레이션이 필요합니다.

3. 요청 본문으로 보내지 않아야하는 캐시하는 모든 필드에는 @Transient 주석이 필요합니다. (???)

4. DTO에서 사용되는 Field는 네트워크에서든, DB에서든 동일한 데이터타입이어야 합니다.

 

결과적으로 유지보수나 변경 사항이 발생했을때에 더 많은 자원이 필요하기 때문에, 처음부터 분리하는 것이 더 좋다고 느껴집니다.

 

마지막으로 Repository (2021.06.17)