도메인의 퍼시스턴스 계층을 담당할 Repository의 탄생(DAO vs REPOSITORY)

2012/03/17 22:57

도메인의 퍼시스턴스 계층을 담당할 Repository의 탄생 Domain Driven Design

DAO vs REPOSITORY

DAO는 데이터베이스에서 값을 꺼내와 도메인 오브젝트로 반환해주거나 적절한 값으로 반환해주는 계층을 일컫는다. Repository는 한 도메인 오브젝트에 대해서 객체의 값을 보증해주기 위해 도메인 내부에서 데이터베이스와 소통하는 객체을 일컫는다.

솔직히 필자가 Repository에 대해 어떠한 식견을 내세우기엔 너무 내공높은 개발자들이 무섭게 각을 내세우고 있는데다 Repository의 필요성 또한 갈수록 줄어드는 추세인 듯 하여 조금 비관적인 이야기로 시작해볼까한다. 

필자가 생각하는 프로그래밍이란 예술이나 문화의 범주에 속하는 것이 아니며 철저히 산업에 기반하는 학문의 일종이다. 그러므로 프로그래밍의 발전은 어디까지나 사용하는 기업의 입장, 그리고 개발자들의 업무상 요구하는 형태를 적극 반영하여 제작되어온데다 그동안 과거를 돌이켜 볼 때 기업과 개발자들의 지지를 받지 못한 기술은 곧잘 사라지곤 했었다.

무작정 다수결의 논리로 필요없어진 기술은 적자생존의 법칙에 따라 물러나야 한다는 이야기는 아니다. 왜냐하면 당장에 필요없어진 기술적 논리가 10년 뒤에 엄청난 발전을 가져오기도 하고 또 지금 잘나가는 기술이 한순간에 새로운 기술로 오버랩되어 사라지는 곳이 IT업계이니 말이다. 필자가 말하고자 하는 것은 당장에 DAO와 REPOSITORY가 너무 거대한 교집합의 영역을 갖고 있고 개발 시에 둘 모두를 함께 끌고 가기엔 코드의 중복이 너무도 심하다는 뜻이다.

프로그래밍의 발전이란 결국 리팩토링의 역사이며 지금의 모든 프로그래밍의 기술이 리팩토링에 기반했다해도 과언이 아닌데 두 계층을 지지하는 세력들의 충돌이 확고하다고 하여 DAO와 Repository의 코드중복은 무시한 채 둘 다 사용할 수는 없는 노릇이다. 필자는 어느 한쪽만은 지지하기 보다는 어느 정도 절충을 하여 개발자는 개발이 시작되기 전에 전반적인 흐름을 미리 파악하고 둘 중 어느 것을 사용할지 양자택일해야 한다고 생각한다.

DDD는 4Tier 아키텍쳐이며 굉장히 객체지향적인 설계를 가능케 하지만 반대로 굉장히 무겁고 어느 정도 성능에 무리를 많이 주는 방식이다. 만약에 당신이 이런 단점을 감안하고 속도보다 사용자의 입장을 고려해서 개발한다면 완전한 DDD 방식의 어플리케이션을 개발할 수가 있다. 이럴 경우엔 DAO보단 Repository를 작성하는 것이 어울릴 것이다. 반대로 당신이 어느 정도 속도도 고려하여 전체적인 어플리케이션의 로직의 중심이 Service 계층과 도메인 계층 사이에 두고 싶다면 DAO가 어울릴 것이다.

어디까지나 선택은 개발자의 몫이다. 다만 DAO와 Repository를 같이 사용하는 것은 아무리 내가 초보라지만 바보같은 짓 같다.

Repository

무엇을 사용하기에 앞서 DAO와 Repository는 무엇인지 간략하게 살펴보도록 하자. Repository는 저장소란 뜻을 가진 단어이다. 그리고 Repository는 DAO처럼 하나의 거대한 계층을 이루고 있지 않으며 도메인 오브젝트의 내부에 위치하여 해당 오브젝트만을 위한 기능을 제공해준다. 겸손한 DAO라고 보면 될 듯 싶다.

public class SimpleProduct implements Product {

private String id;
private String name;
private ProductRepository productRepository;

public String getName() {
if(name==null) return userReponsitory.getName(getId());
else return name;
}

… 중략 …
}  

이전 장을 꼼꼼히 읽어본 뒤에 위의 예제를 이해했다면 아마 많은 독자가 DAO와 Repository의 기능이 별반 다르지 않다는 사실을 알게 될 것이다. 실제로도 그렇다. 두 객체의 차이점은 DAO는 도메인 바깥에 위치해서 해당 도메인을 위한 기능 외에도 다양한 기능을 갖고 있다는 점과 Repository는 도메인 내부에 위치하여 오로지 도메인을 위해서만 동작한다는 점 뿐이지 똑같이 데이터베이스에 접근하는 액세스 포인트를 갖고 있다.

그러나 두 오브젝트의 개념은 미묘하면서도 확실히 차이를 두어야 할만큼 다르기 때문에 개발자가 분명히 해두어야할 부분이다. 만약 해당 Repository가 만약 도메인 외부에서도 떠돌아 다닌다면 그것은 더이상 Repository가 부를 수 없으며 분명한 DAO 객체이다. 반대로 오로지 도메인을 내부에만 위치하면 도메인을 위해서만 기능하는 DAO가 있다면 그것은 더이상 DAO 객체라 부를 수 없다. 그러므로 사전에 어플리케이션을 설계할 때 만약 당신이 서비스 계층을 고려하여 도메인 계층과 서비스 계층을 둘다 이용하는 것을 고려한다면 DAO를 적극 활용할 것이고 반대로 서비스 계층을 최소화 하고 도메인 계층에 대부분의 로직을 부여한다면 Repository를 이용하는 방식을 이용하게 될 것이다.

다음 장부터는 Domain Driven Design을 활용하여 직접 전자상거래 시스템을 기획, 설계하는 과정을 거쳐볼 것이다. 사실 DDD란 아직 MVC만큼이나 확고한 설계방침을 가진 아키텍쳐는 아니므로 개발자마다 독자적으로 해석한 메서드, 또는 클래스들이 존재하기 마련이다. 필자가 구현하는 전자상거래 또한 어느 정도 자해석된 영역이 존재할 수도 있다는 점을 유의해주길 바란다.

by 거짓말

출처 - http://springmvc.egloos.com/543686