인프런 커뮤니티 질문&답변

안녕하세요.

결제 부분 강의를 보니 payments API를 보면 컨트롤러에서 주문을 조회하고, 사용 할 쿠폰을 조회하고, 포인트를 조회하고, 조회 된 데이터를 PaymentService로 전달하는 스타일이더라구요.

제가 진행중인 사이드 프로젝트도 커머스가 주제입니다. 제 프로젝트도 처음에는 강의 코드 스타일대로 컨트롤러에서 필요한 데이터를 조합하고, 결제를 처리하는 Service 쪽으로 넘기는 형식이었는데,
이게 점점 결제 기능이 고도화되면서 뭔가 컨트롤러에서 비즈니스 로직의 흐름이 보이는게 맞나? 라는 생각이 들게 되었고 어느 순간부터 웬만한 Controller에서는 1개의 xxxService.method()만 호출하고 이 method가 요청에 대한 비즈니스 로직을 전부 담당하게 되었습니다.

@Service
class QuestionPaymentService(
    private val questionOrderGenerator: QuestionOrderGenerator,
    private val promotionApplier: PromotionApplier,
    private val orderCouponApplier: OrderCouponApplier,
    private val paymentCouponApplier: PaymentCouponApplier,
    private val questionPaymentRecorder: QuestionPaymentRecorder,
    private val pointCommandAPI: PointCommandAPI,
    private val eventPublisher: EventPublisher,
) {
    @Transactional
    fun payment(command: QuestionPaymentCommand): QuestionPayment {
        val order = questionOrderGenerator.generateQuestionOrder(command.userId, command.questionIds)
        val questionPayment = QuestionPayment.create(command.userId, order)
        
        promotionApplier.apply(order)
        orderCouponApplier.apply(questionPayment, command)
        
        paymentCouponApplier.apply(questionPayment, command)
        pointCommandAPI.usePoint(questionPayment.userId, questionPayment.realAmount)
        questionPaymentRecorder.record(questionPayment)
        
        eventPublisher.publish(toEvent(questionPayment))
        return questionPayment
    }
}

위 코드는 제 프로젝트의 결제 부분인데요. 강의에서 말씀하신 것처럼 Service가 너무 많은 걸 알게되더라구요.
(주문도 생성하고, 쿠폰도 적용하고, 프로모션도 적용하고...)
지금 이 글을 작성하다보니, 갑자기 제 코드가 못생겨보이네요..

강의 코드와 비슷한 방식으로 위 코드를 바꿔본다면, 컨트롤러에서는 orderService를 이용해서 주문을 생성하고, couponService, promotionService 등을 이용해서 전처리를 한 뒤 PaymentService을 이용해
실 결제 금액만큼 금액을 지불하도록 하는 로직과 결제 내역을 저장하는 로직만 있을 것 같아요.

반대로 제 프로젝트 방식대로 강의 코드의 payments API를 만들어본다면, Payment를 만들기 위해서
PaymentCreateService와 같은 곳에서, orderReader, ownedCouponReader, pointReader 등을 조합해서 Payment를 생성하는 방식이 될 것 같아요.

결국 Service가 적은 책임만 가지게 된다면, Controller 입장에서는 복잡한 요청을 처리하기 위해선 다양한 Service를 조합하게 되고 Controller가 비즈니스 로직의 흐름을 보여주는 형태가 될 수 있다고 생각이 드는데요.
(사실 Controller가 비즈니스 로직의 흐름을 보여주면 안된다는 걸 어디서도 듣지 않았지만 뭔가 어색한 것 같아요.)
물론 계속 말씀하시는것 처럼 정답은 없다는 것은 알지만, 그냥 단순히 재민님은 주로 많은 책임을 가지는 Service보다는 Controller에서 작은 단위의 Service로 조합해서 처리하는 것을 선호하시는지 궁금합니다.

재민님을 지속 성장 가능한 소프트웨어 포스팅으로 알게되었고, 유튜브에서도 많은 도움이 되었어요.

그렇게 얻은 다양한 인사이트들을 개인 프로젝트에도 적용해보면서 다양한 시도를 하고 있는데 마침 제 관심사인 커머스 주제로 강의가 나와서 정말 행복합니다.