Repository와 DAO의 차이점은 무엇일까

 

 

 

🧐 서론

Repository와 DAO에 관해서 헷갈려 하는 분들이 되게 많은 것 같다는 것을 느끼고 있습니다.

저도 처음 해당 두 용어를 접했을 때에는 굉장히 혼동스러웠던 기억이 있습니다.

 

이번 글에서는 위 두 용어에 대해서 각각 어떤 의미를 갖고 어떤 식으로 사용되는지 살펴봄으로써 고민을 조금 해결해 보는 시간을 가지려 합니다.

 

결론만 보고 싶으시다면, 맨 아래로 내려가셔도 됩니다.

 

 

 

 

 

 

 

 

🧐 DAO

Data Access Object의 줄임말인 DAO는 해석 그대로 데이터에 접근하는 객체를 의미합니다.

조금 더 풀어서 설명하자면, DAO는 데이터베이스 혹은 다른 영속성(Persistence) 메커니즘에 대한 접근을 추상화해주는 역할을 수행합니다.

 

즉 어떤 데이터베이스를 사용할 것인지, 혹은 어떤 영속성 저장 방식을 사용할 것인지에 대해서 응용 계층에서는 신경쓰지 않도록 만들어 주는 역할을 수행합니다.

 

 

DAO를 사용하지 않으면 어떠한 문제점이 있는지, 아래 예시를 통해 살펴보도록 하겠습니다.

 

 

 

 

🤔 DAO 를 사용하지 않는 경우 발생하는 문제점

다음 코드는 간단하게 주문을 생성하는 로직을 처리하는 코드입니다.

@Service
@Transactional
public class OrderService {

    public void order(final PlaceOrderCommand command) {
        Order order = command.toDomain();
        order.place();
        save(order);
    }

    private void save(final Order order) {
        // [MYSQL] DB Connection 을 획득하는 코드
        String saveSql = "INSERT INTO ORDERS(id, user_id, order_time, status) VALUES(?, ?, ?, ?)";
        // 대충 파라미터 바인딩하고, DB에 저장하는 코드
    }
}

public class PlaceOrderCommand {

    private final Long userId;

    public PlaceOrderCommand(final Long userId) {
        this.userId = userId;
    }

    public Order toDomain() {
        return new Order(userId, "beforePlace");
    }
}

public class Order {

    private Long id;
    private Long userId;  // 주문자 ID
    private LocalDateTime orderTime;  // 주문시간
    private String status;  // 주문상태

    public Order(final Long userId, final String status) {
        this.userId = userId;
        this.orderTime = LocalDateTime.now();
        this.status = status;
    }

    public void place() {
        status = "placed";
    }
}

 

위 코드를 보면 Application(Service) 계층에서 데이터베이스에 직접적으로 의존한다는 것을 알 수 있습니다.

만약 MYSQL 대신에 Oracle로 데이터베이스를 변경해야 한다는 요구사항이 들어온다면, Application의 코드를 수정해야 하는 상황이 발생합니다.

즉 변경에 취약해지는 것입니다.

 

 

이러한 문제를 해결하기 위해 DAO를 도입합니다.

 

 

 

 

🤔 DAO 를 사용하여 해결

DAO를 사용하면 위 코드는 아래와 같이 변경됩니다.

@Service
@Transactional
public class OrderService {

    private final OrderDao orderDao;

    public PlaceOrderService(final OrderDao orderDao) {
        this.orderDao = orderDao;
    }

    public void order(final PlaceOrderCommand command) {
        Order order = command.toDomain();
        order.place();
        orderDao.save(order);  // 무슨 DB를 쓰는지 노출되지 않는다.
    }
}

public class PlaceOrderCommand {

    private final Long userId;

    public PlaceOrderCommand(final Long userId) {
        this.userId = userId;
    }

    public Order toDomain() {
        return new Order(userId, "beforePlace");
    }
}

public class Order {

    private Long id;
    private Long userId;  // 주문자 ID
    private LocalDateTime orderTime;  // 주문시간
    private String status;  // 주문상태

    public Order(final Long userId, final String status) {
        this.userId = userId;
        this.orderTime = LocalDateTime.now();
        this.status = status;
    }

    public void place() {
        status = "placed";
    }
}

위 코드만을 통해서는 어떤 데이터베이스, 혹은 다른 영속성 메커니즘을 사용하는지 전혀 알 방법이 없습니다.

 

영속성과 관련된 기능 구현은 OrderDao 내부에서 담당합니다.

 

이를 통해 Application에서는 영속성 메커니즘에 대해 신경쓰지 않을 수 있게 되었으며, 따라서 이전에 발생했던 데이터 저장소가 바뀌는 경우 Application 레이어의 코드가 변경되는 문제가 해결된 것입니다.

 

DAO는 데이터베이스를 사용한다면 보통 DB 테이블과의 매핑을 책임으로 가집니다.

즉 데이터베이스 테이블이 order, user, xxx 등등 존재한다면, DAO는 OrderDao, UserDao, XxxDao 등으로 존재하게 됩니다.

 

보통 DAO는 (DB를 사용한다면) DB 테이블과 1대1 매핑을 시켜 사용합니다.

 

 

 

 

 

 

 

 

 

 

🧐 Repository

Repository는 DDD에서 등장한 개념입니다.

Repository를 이해하기 위해서는 DDD에 대한 지식(Aggregate 등)을 알면 더 도움이 되겠지만, 여기서는 간단하게만 살펴보도록 하겠습니다.

 

우선 위 코드를 조금 더 발전시킨 후, 어떠한 문제점이 발생하는지를 알아보도록 하겠습니다.

 

주문(Order)을 할 때에는, 당연히 주문 상품(OrderItem)들이 있어야 합니다.

 

대부분의 경우 하나의 주문에는 여러개의 주문 상품이 포함될 수 있는데요, 이를 도메인 모델로써 구현하면 다음과 같습니다.

public class Order {

    private Long id;
    private Long userId;  // 주문자 ID
    private LocalDateTime orderTime;  // 주문시간
    private String status;  // 주문상태

    private List<OrderItem> orderItems = new ArrayList<>();  // 주문 항목들

    public Order(final Long userId, final String status, final List<OrderItem> orderItems) {
        this.userId = userId;
        this.orderTime = LocalDateTime.now();
        this.status = status;
        this.orderItems.addAll(orderItems);
    }

    public void place() {
        status = "placed";
    }

    public List<OrderItem> orderItems() {
        return orderItems;
    }
}

public class OrderItem {

    private Long id;
    private String name;  // 상품 이름
    private int price;  // 상품 가격
    private int count;  // 상품 개수

    public OrderItem(final String name, final int price, final int count) {
        this.name = name;
        this.price = price;
        this.count = count;
    }
}

 

 

 

 

🤔 Repository 를 사용하지 않는 경우 발생하는 문제점

주문을 저장할 때에는 주문 상품들 또한 저장을 해야 합니다.

또한 주문 조회시 주문 상품들도 같이 조회되어야 하고, 주문 제거 시 주문 상품들도 같이 제거되어야 합니다.

 

이를 위해서는 주문 상품에 대한 데이터베이스 테이블을 만들어야 하고, 그에 따라 DAO도 만들어야 합니다.

 

이제 기존 코드를 수정해서, 주문을 저장하고, 조회하고, 제거하는 기능을 구현해 보도록 하겠습니다.

@Service
@Transactional
public class OrderService {

    private final OrderDao orderDao;
    private final OrderItemDao orderItemDao;

    public PlaceOrderService(final OrderDao orderDao, final OrderItemDao orderItemDao) {
        this.orderDao = orderDao;
        this.orderItemDao = orderItemDao;
    }

    public void order(final PlaceOrderCommand command) {
        Order order = command.toDomain();
        order.place();
        orderDao.save(order);  // 주문 저장
        orderItemDao.saveAll(order.orderItems());  // 주문상품 저장
    }
    
    // 주문 조회 시 주문 상품들 또한 같이 조회되어야 한다.
    public Order findOrderById(final Long id) {
        Order order = orderDao.findById(id);
        List<OrderItem> orderItems = orderItemDao.findAllByOrderId(id);
        order.setOrderItems(orderItems);
        return order;
    }
    
    // 주문 삭제 시 연관된 주문들 또한 같이 삭제
    public void deleteOrderById(final Long id) {
        orderItemDao.deleteAllByOrderId(id);
        orderDao.deleteById(id);
    }
}


class PlaceOrderCommand {

    // 생략
    
    public Order toDomain() {
        final List<OrderItem> orderItems = placeOrderItems.stream()
                .map(PlaceOrderItem::toDomain)
                .collect(Collectors.toList());
        return new Order(userId, "beforePlace", orderItems);
    }

    public class PlaceOrderItem {
        // 생략
    }
}

class Order {
    // 생략
}

class OrderItem {
    // 생략
}

 

 

주문 저장 시 주문 상품들도 같이 저장하기 위하여 OrderService의 코드가 수정되었습니다.

 

만약 주문과 함께 저장되고, 조회되고, 변경되어야 하는 것들이 늘어난다면 이로 인해 Application Layer의 코드도 계속해서 변경되어야 합니다.

 

이러한 문제의 원인은 다음과 같습니다.

도메인 모델 내의 참조에 대한 캡슐화가 이루어지지 않았기 때문에 발생한 일입니다.

주문이 주문 아이템을 참조한다는 것은 OrderService에 노출될 필요가 없습니다.

주문을 저장할 때, 알아서 참조하는 주문 항목들도 같이 저장되도록 한다면 OrderService의 복잡도가 줄어들 것입니다.

Repository를 도입함으로써 이러한 목적을 달성할 수 있습니다.

 

 

 

 

 

 

 

🤔 Repository 를 사용하여 문제 해결

여러 글들에서는 'Repository는 객체 Collection의 추상화'라고 설명합니다.

 

저는 해당 설명에 조금 더 살을 붙여보려 합니다.

Repository는 함께 저장되고, 함께 조회되며, 함께 변경되는 여러 도메인 모델 사이에서,
이들의 진입점 역할을 할 수 있는 도메인 엔티티에 대한 컬렉션처럼 동작합니다.

 

예를 들어, 주문과 주문상품은 함께 저장되고, 함께 조회되며, 함께 변경됩니다.

그리고 주문 상품들은 주문을 통해서 접근할 수 있으며, 주문 내에서만 의미를 가집니다.

따라서 주문과 주문 상품들 중 진입점 역할을 할 수 있는 도메인 엔티티는 주문이며, Repository는 주문에 대해서만 존재해야 합니다.

 

Repository를 도입하여 위의 코드를 수정해 보겠습니다.

@Service
@Transactional
public class OrderService {

    private final OrderRepository orderRepository;

    public PlaceOrderService(final OrderRepository orderRepository) {
        this.orderRepository = orderRepository;
    }

    public void order(final PlaceOrderCommand command) {
        Order order = command.toDomain();
        order.place();
        orderRepository.save(order);  // 내부적으로 Order와 OrderItem을 함께 저장한다.
    }
    
    public Order findOrderById(final Long id) {
        return orderRepository.findById(id); // 조회된 Order는 OrderItem이 온전히 세팅되어있다.
    }
    
    // 주문 삭제 시 연관된 주문들 또한 같이 삭제
    public void deleteOrderById(final Long id) {
        orderRepository.deleteById(id);  // 내부적으로 Order와 OrderItem을 함께 제거한다.
    }
}


class PlaceOrderCommand {
    // 생략
}

class Order {
    // 생략
}

class OrderItem {
    // 생략
}

 

즉 연돤관계를 가진 도메인 모델들의 참조를 추상화하고, 연관된 도메인 모델들 중 이들의 진입점 역할을 하는 객체에 대한 Repository를 제공함으로써 Application Layer의 복잡도가 낮아진 것을 알 수 있습니다.

 

 

 

 

 

 

 

 

🧐 결론

DAO와 Repository 둘 다 데이터베이스(혹은 기타 영속성 메커니즘) 접근을 캡슐화하는 역할을 수행합니다.
(편의를 위해, 데이터베이스를 가정하고 이어가겠습니다.)

대체로 DAO는 DB 테이블과 1대1 매핑을 시킵니다.

Repository의 경우 생성하는 기준이 DB 테이블이 아닙니다.
Repository는 연관이 있고, 함께 변경되어야 하는 여러 도메인 모델 사이에서, 이들의 진입점 역할을 할 수 있는 도메인 엔티티에 대해서만 Repository를 구현합니다.

도메인 엔티티에 연관된 객체가 없어, 도메인 엔티티가 DB 테이블에 1대1로 매핑되는 경우도 있습니다.
그러면 결국 1개의 Repository와 1개의 DAO를 사용하는 형식이 되므로, 이러한 경우에는 Repository와 DAO는 별 차이가 없어집니다.

결론적으로 DAO는 DB에 조금 더 연관성이 있으며,
Repository는 도메인 모델에 조금 더 연관되어 있습니다.

 

(너무 믿지는 마세요 ^^ 그냥 실무 경험 없는 코딩 왕초보의 생각 정리글입니다.)

(당연하게도 문맥에 따라 조금씩 달라질 수도 있습니다. 뭐 CQRS를 사용하는데 쿼리용 데이터 접근 클래스를 DAO, 명령에 해당하는 데이터 접근 클래스를 Repository로 쓴다거나 뭐... 아무튼요)

 

 

 

 

 

📚 Reference

도메인 주도 설계 - 에릭 에반스

도메인 주도 개발 시작하기 - 최범균님

그동안 봐왔던 여러 글들과, 직접 사용해보며 들었던 나의 생각