Feature: 티켓 예매를 위한 결제 기능을 구현한다. #45
Conversation
seminchoi
requested review from
mirageoasis,
hseong3243 and
lass9436
as code owners
| simulateRandomDelay(random); | ||
|
|
||
| // 5% 확률로 결제 실패 예외 발생 | ||
| if (random.nextInt(100) < 5) { |
There was a problem hiding this comment.
사실 이 곳은 음... 일단 성공한다고 짜는게 맞지 않을까요?
개인적인 생각으로 에러 처리 보다는 다른 기능 구현이 우선이라고 생각합니다.
주석처리하고 나중에 살리는 방안 어떤가요?
There was a problem hiding this comment.
알겠습니다 실패는 나중에 다시 고려해보는 걸로 하겠습니다~!
There was a problem hiding this comment.
궁금한게 이러면 결제는 어떤 방식으로 이뤄지는건가요?
결제는 따로 구현할까요?
어디서 티켓에 유저, 좌석 기록하는거죠?
There was a problem hiding this comment.
결제 프로세서에서는 결제만 수행하고 회원, 좌석 상태 변경은 TicketService 쪽에서 수행하는게 더 책임에 맞다고 생각했습니다!
결제 완료에 대한 응답으로 Return 타입을 바꿔야할 수도 있을 것 같긴 합니다.
There was a problem hiding this comment.
그러면 일단 급한대로 TicketService에서 결제 서비스를 부르는 방식으로 할까요?
There was a problem hiding this comment.
넵 TicketService 클래스에 필드로 추가해놓았습니다!
seminchoi
force-pushed
the
feature/payment-interface
branch
from
5153f64
to
b80e049
Compare
|
|
||
| @Component | ||
| @Slf4j | ||
| public class SimulatedPaymentProcessor implements PaymentProcessor { |
There was a problem hiding this comment.
결제 실패를 가정하는 프로세서라면 @Component를 붙여서 관리하는 것은 적절하지 않은 것 같습니다!
만약 빌드를 위해 main 패키지에 구현체를 두어야 한다면 아무런 행위를 수행하지 않는 더미 객체를 두고, 결제 실패 프로세서는 test 패키지로 빼는게 좋을 것 같습니다!
There was a problem hiding this comment.
이미 현우님이 코멘트 달아주신 것 같지만 제 의견도 첨부합니다!
There was a problem hiding this comment.
부하 테스트할 때 결제 지연에 따라서 얼마나 부하를 견딜 수 있는지 테스트하려면 구현코드에 해당 컴포넌트가 있어야 할 것 같습니다..!
다른 방법이나 의견이 있을까요?
There was a problem hiding this comment.
결제 지연에 따른 정확한 테스트를 하려면 코드로 해결하기 보다 가짜 결제 서버를 따로 만들어서 실제 통신하듯이 네트워크를 태우면 더 좋을 것 같아요! 지금은 아니더라도 나중에 테스트할 때 이 클래스의 로직을 가짜 서버로 옮겨보는 건 어떨까요?
There was a problem hiding this comment.
네트워크 I/O 에 따른 부하는 또 조금 다를 수 있겠네요. 부하테스트 할 때 고려해보겠습니다!
⛏ 작업 사항
티켓 예매를 위한 결제 기능을 인터페이스로 정의했습니다.
결제 지연, 결제 실패를 가정한 결제 시뮬레이션 구현체를 구현했습니다.
📝 작업 요약
💡 관련 이슈