DAO와 Repository를 분리했던 이유

문제상황

지하철 미션을 진행하면서 db에서 가져온 데이터를 어떤 식으로 다뤄야할지에 대해 많이 고민했다.
db에서 데이터를 가져오면서 값을 받아 객체로 넘겨 처리를 할 때
너무 복잡해지고 스스로가 이해할 수 없는 코드가 되고 있었다.
 
또한 DAO만 사용했을 경우는 Service계층에서 코드가 복잡해졌다.
도메인 엔티티를 만들기 위해서 그에 필요한 많은 로직들이 생기는 경우가 있었다.
특히 연관관계가 있는 경우에는 더 그렇다.
도메인에서 다른 객체의 상태를 가지고 있는 경우 해당 객체도 함께 생성해줘야하므로 코드가 복잡해지게 된다.
 

사용이유

Repository에서 그 책임을 담당한다면 서비스도 당연히 로직이 줄어들고,
도메인을 생성하는 책임이 있다는 것이 명확이 드러나서 훨씬 보기에 편했다.
물론 다른 계층, 즉 클래스가 더 생기기에 한번 더 확인해야하는 비용이 있지만
로직이 깔끔하다는 것은 유지보수에 훨씬 유리하다는 생각이 들었다.
 

도입방식

그래서 가장 먼저 도입했던 방식은 도메인 엔티티와 영속성 엔티티를 구분하는 것이었다.
영속성 엔티티는 db에서 가져온 값을 그대로 받아서 가지고 있는 엔티티 클래스를 의미한다.
도메인 엔티티는 프로그램 내부에서 로직과 함께 사용되는 비즈니스 개념의 엔티티 클래스라고 생각한다.
따라서 영속성 엔티티를 통해서 db에 직접적으로 데이터를 받아와서
필요에 따라 도메인 엔티티로 넘겨주는 방식을 사용해보았다.

이를 위해서는 DAO와 Repository를 분리하여 사용하는 것이 좋다고 생각했다.
DAO는 단순히 Data Access Object라는 의미를 수행해야한다고 생각했고,
db에 접근하여 데이터를 가져오는 역할을 하는 것이 좋다고 생각했다.
그리고 이에 영속성 엔티티를 반환하는 책임을 가지게 했다.
 
그리고 Repository에는 DAO에서 넘겨받은 영속성 엔티티를 도메인 엔티티로 변환하여 넘겨준다.
즉 Repository는 도메인 엔티티를 반환하는 책임을 가진다.
 

결과

결과는 만족스러웠다.
객체를 반환하는 부분을 찾기 위해서는 Repository만 보고 찾아가면 되었다.
또한 객체 생성에 문제가 있다면 Repository를 찾아서 보면 된다.
쿼리가 문제가 있거나 데이터와 직접 접근하는 부분에서 문제가 생긴다면 DAO를 확인하면 된다.
각각은 서로 역할이 확실하게 하나로 정해져있어서
에러가 발생했거나, 리팩터링을 할 때에 훨씬 편하게 로직을 이해하고 수정할 수 있었다.
 
그렇다고 무조건 도메인 엔티티와 영속성 엔티티를 구분해야한다는 것은 아니다.
테이블 관계가 간단하고 연관관계가 복잡하지 않다면 도메인 엔티티만으로도 충분한 경우도 있다.
도메인 객체를 생성할 때 연관관계로 인해 로직이 복잡해지는가를 먼저 생각하고,
분리가 필요하다면 코드레벨 전체에 계층을 분리하는 것이 좋다고 생각한다.
 
한두개를 제외한 간단한 로직들은 도메인 엔티티를 사용하는 것이 더 간편할지언정
계층을 구분할 때는 통일성있게 적용하는 것이 좋다고 생각한다.
따라서 앞으로는 필요하다면 전체적으로 분리를 적용하는 방식을 택할 것 같다.