요구사항이 복잡해지면서 나타나는 도메인 강한 결합에 대하여

[YehyeokBang]

상황

방탈출 예약 애플리케이션이 있다고 가정하자.
사용자는 예약할 수 있고, 이미 예약된 경우 대기를 요청할 수 있다.

예를 들어,
A 사용자가 예약을 하고, B 사용자가 해당 예약에 대기를 요청했다.
이후 A 사용자가 예약을 취소하면, B 사용자의 대기를 자동으로 승인하여 예약으로 전환해야 하는 시나리오가 발생할 수 있다.

기능 추가로 인한 도메인 결합

방탈출 예약 애플리케이션에서 대기 자동 승인 기능을 추가하려 했을 때, 예상보다 큰 변경이 필요했다.

기존 예약 서비스는 단순한 예약 취소 기능만 담당하고 있었다.

// ReservationService
public void cancel(Long reservationId) {
    reservationRepository.deleteById(reservationId);
}

하지만 자동 승인을 위해 대기 도메인의 존재를 알아야 한다. (의존성과 다른 도메인과 관련된 기능 추가)

public void cancel(Long reservationId) {
    reservationRepository.deleteById(reservationId);
    if (waitingRepository.exists()) {
        // 가장 먼저 등록된 대기자를 예약으로 전환
    }
}

결제가 도입된다면 또 다른 의존성이 추가될 수밖에 없다.

public void cancel(Long reservationId) {
    reservationRepository.deleteById(reservationId);
    if (waitingRepository.exists()) {
        // 대기 자동 승인
    }
    payment.cancel(); // 결제 취소 처리
}

문제 요약

• 예약 도메인이 다른 도메인(대기, 결제 등)과 강하게 결합되며, 단일 책임 원칙이 약해진다.
• 하나의 기능(예약 취소)을 위해 다양한 도메인을 직접 알아야 한다. (높은 결합도)
• 새로운 도메인 기능이 추가될 때마다 기존 예약 서비스의 변경이 불가피하다. (OCP 위반 가능성)
• 결과적으로 서비스가 비대해지고, 유지보수와 확장이 어렵다.

현재 구조는 결국 도메인의 강한 결합으로 이어지고, 하나의 서비스가 다양한 책임을 갖게 되는 구조가 된다.

해결 방향 (고민 중)

아직 명확한 해결책은 찾지 못했지만, GPT를 통해
이벤트 기반 처리(event publisher/subscriber)나 중재자 패턴 같은 간접 의존 구조를 도입하면 문제를 완화할 수 있다는 내용을 알게 되었다.

예약 취소 시 예약 취소됨이라는 이벤트를 발행하고,
대기 도메인은 이 이벤트를 수신해 별도로 자동 승인을 처리하는 구조?

이 부분에 대해 더 학습해보면 좋을 것 같다.

[YehyeokBang]

수정 예정 (간단한 테스트)

예약을 취소하는 서비스에서는 검증 및 삭제 후 이벤트만 발행한다.
이후 이 이벤트를 바라보는 객체가 자동 승인 기능을 구현했다.

@Service
@Transactional
public class DeleteReservationService {

    private final ReservationRepository reservationRepository;
    private final ApplicationEventPublisher eventPublisher;

    public DeleteReservationService(ReservationRepository reservationRepository,
                                    ApplicationEventPublisher eventPublisher) {
        this.reservationRepository = reservationRepository;
        this.eventPublisher = eventPublisher;
    }

    // 검증 및 삭제 후 특정 예약이 취소되었다는 이벤트를 발행
    public void removeById(Long reservationId) {
        Reservation reservation = reservationRepository.findById(reservationId)
                .orElseThrow(() -> new IllegalArgumentException("예약 정보가 존재하지 않습니다."));
        reservationRepository.deleteById(reservationId);
        eventPublisher.publishEvent(new ReservationCancelEvent(
                reservation.getDate(),
                reservation.getTheme().getId(),
                reservation.getTime().getId()
        ));
    }
}

// 전송되는 객체
public record ReservationCancelEvent(
        LocalDate date,
        Long themeId,
        Long timeId
) {
}

@Component
public class ReservationCanceledEventListener {

    private final WaitingRepository waitingRepository;
    private final ReservationRepository reservationRepository;

    public ReservationCanceledEventListener(WaitingRepository waitingRepository,
                                            ReservationRepository reservationRepository) {
        this.waitingRepository = waitingRepository;
        this.reservationRepository = reservationRepository;
    }

    // 취소 이벤트를 받아서, 첫 번째 대기를 찾아서 예약으로 자동 승인
    @EventListener
    @Transactional
    public void handle(ReservationCancelEvent event) {
        waitingRepository.findTop1ByDateAndTimeIdAndThemeIdOrderByCreatedAtAsc(
                event.date(),
                event.timeId(),
                event.themeId()
        ).ifPresent(waiting -> {
            validateReservationIsAvailable(waiting);
            validateWaitingIsFirst(waiting);
            promoteWaitingToReservation(waiting);
        });
    }

    // 기타 분리된 메서드..
}

대충 느껴본 장점

• 결합도 감소: DeleteReservationService는 예약을 취소했다는 사실만 전달한다. 나머지(추가 요구 사항)는 다른 관심사에서 처리한다.
• 도메인 독립성 유지: 대기 자동 승인은 ReservationService와 무관한 책임으로 분리되어 있어 SRP를 준수한다.
• 확장성 확보: 추후 예약 취소 시 알림 발송, 포인트 복구 등도 @EventListener만 추가하면 된다?

학습하고 싶은 내용

• @TransactionalEventListener vs @EventListener
• 이벤트 실패 재시도 (예: Spring Retry, Dead Letter Queue), 트랜잭션 내 예외가 발생해서 롤백되는 경우 대처 방법
  • 이벤트는 언제 실행되는가? → 실패하면 어떻게 복구할까?
• 예약 취소 후 결제 취소가 된다고 할 때 결제 취소가 안되더라도 원활한 대기 관리를 위해 예약 취소 자체는 되어야 한다면?
  • 트랜잭션을 분리하나? 비동기 이벤트 처리 (@Async)
• 다른 문제는 없나?

참고

• Standard and Custom Events, Spring Docs
• 이벤트 기반 트랜잭션 처리, Yun Blog

[YehyeokBang]

학습 블로그 포스팅