DAO와 Repository의 차이?
DAO(Data Access Object)와 Repository는 수행하는 기능적 관점으로만 보면 거의 같다고 생각해도 무방하다.
좀 더 깊이 있게 차이를 찾아보면 DAO는 DB에 연결하여 데이터에 접근하는 것에 관련된 로직을 모아둔 기술적 관점의 계층이고, Repository는 도메인 객체를 저장하고 관리하는 저장소를 추상화한 계층이다.
DAO는 데이터 중심적 관점(데이터베이스 연결, 테이블, SQL이 관심사)의 네이밍이고, Repository는 도메인 중심적 관점(도메인 객체가 관심사)의 네이밍이다.
repository가 더 고수준의 추상화 계층이라고 보는 관점도 있는데, 현재 내 생각으로는 repository 구현체가 dao를 인스턴스로 갖게 하는 구조에 별다른 이점을 느끼지 못하고 있다. repository 인터페이스만으로 기능 명세와 추상화가 충분해보이기 때문이다.
굳이 dao를 분리를 한다면 dao는 데이터베이스 테이블과 1:1 대응관계로 만들고, repository는 dao로부터 조회된 엔티티를 조립하는 정도의 역할밖에 하지 않을 것 같다. 조립 정도의 책임으로 클래스를 분리할만한가에 대해서는 아직 의문이다. 추후 JPA를 사용하게 되면 조립조차 JPA가 효율적으로 다 처리해주는데 더더욱 dao와 repository 분리의 특이점을 찾기 어려울 것으로 보인다. (주관적 의견임)
Spring에서 Repository를 권장하는 이유
All Spring Data modules are inspired by the concepts of “repository”, “aggregate”, and “aggregate root” from Domain Driven Design. These are possibly even more important for Spring Data JDBC, ...
출처: https://docs.spring.io/spring-data/relational/reference/jdbc/domain-driven-design.html
Spring Data JPA, Mongo, Redis 모두 Repository를 기반으로 추상화되어 있다. 이는 DDD에서 유래된 Repository에서 영감을 받은 것이다.
Spring Boot는 특정 아키텍처의 사용을 강제하지는 않지만, Spring Data 등 Spring 생태계가 DDD의 개념을 적극적으로 지원하는 것으로 보인다.
그러므로 Spring Boot를 활용할 때는 DDD 기반의 설계를 하는 것이 자연스럽고 이점이 많을 것 같다.
DDD를 벗어나 나만의 방식으로 설계하는 것은 수파리의 "파" 단계가 되어서 도전해볼 일 같다.
아직 익숙하진 않지만 Spring Boot의 철학을 일단 그대로 느껴보자.
