payment 상태 업데이트 변경 메서드를 3개나 두는 이유가 궁금합니다.
229
1 asked
강의 30분 40초에 보시면 success, failure, unknown 이렇게 상태를 변경하면서 메서드를 3개나 두시는데 이유가 궁금합니다. 만약 jpa나 querydsl을 사용한다면 코드가 달라질까요?
Answer 2
0
ai 답변이라 만족스럽지 않네요 ㅠ native sql을 커스터마이징하기 어려워서 이렇게 처리하셨는지가 요점입니다. 상태를 업데이트해야하는 것이고, 구조를 다르지 않아서 파라미터들을 이용해서 메서드를 하나로 통합할 수 있다고 생각했는데, 결제 도메인? 이라서 따로 메서드를 두신 이유가 있었나 싶었습니다. 상태변경 포인트를 메서드를 하나로 관리한다면 유지 보수에 용이할 것이라고 생각합니다. 나중에 읽어보신다면 답변 부탁드립니다!
0
안녕하세요, 인프런 AI 인턴입니다.
victor님, 그 부분에 대한 답변입니다.
결제 시스템에서 상태 업데이트 메서드를 success, failure, unknown으로 구분해서 사용하는 이유는 각 상태 변경에 대한 명확한 구분과 추가적인 처리를 위함입니다. 결제 과정에서 상태별로 다른 로직이나 검증, 사이드 이펙트를 처리해야 할 수 있기 때문에 이렇게 분리하는 것이 유지보수성 및 가독성 면에서 좋습니다.
JPA나 QueryDSL을 사용한다고 해도, 내부적으로 상태를 업데이트하는 로직의 기본적인 이유와 원칙은 변하지 않습니다. 다만, JPA나 QueryDSL을 활용하면 상태 업데이트를 위한 코드 작성 방식이나 데이터베이스와의 인터랙션 방식이 변경될 수 있습니다. 예를 들어, JPA를 사용할 경우 엔티티 매니저를 통해 객체의 상태를 변경한 후 트랜잭션을 커밋하는 방식으로 데이터베이스 반영이 이루어지며, QueryDSL을 사용할 경우에는 좀 더 유연하고 동적인 쿼리 구성이 가능할 것입니다.
그렇지만 이러한 기술적인 선택 또는 사용 방법과는 별개로, 상태 업데이트 메서드를 목적별로 분리하여 관리하는 것은 해당 시스템의 설계 원칙이나 비즈니스 로직의 명확성을 위해 선택할 수 있는 좋은 방법입니다.
프로그램 아키텍쳐
0
60
1
실습코드 압축해제
0
77
1
confirm 로직에서 amount를 검증하는 부분에서 질문이 있습니다.
0
52
1
Transaction Demo 질문 드립니다.
0
59
1
cdc 방식
0
82
1
seed 키 및 orderId 에 대한 질문
0
64
1
결제 이후 404 Error 발생
0
160
1
테스트 코드 중 isPaymentDone 변환
0
75
1
가상의 Checkout 기능 구현 중 질문
0
183
1
docker Mysql 설정 문의
0
105
1
allOpen 설정이 잘못된 거 같습니다.
0
114
1
recovery 동시성 처리 관련 문의
0
117
1
confluent > skip 이 더이상 안되나봅니다.
0
106
1
강의 클론 코딩한 것 public repo에 올려도 되나요?
0
330
1
멱등키에 request를 넘기는 것
0
255
1
동시성 제어 (optimistic locking) 재시도 부분 질문 드립니다.
0
172
1
결제 복구의 세부 과정을 병렬로 처리한 이유가 궁금합니다
0
222
1
전체적인 헥사고날 아키텍쳐 설명
0
275
1
주문, 결제 로직에 대해서 질문이 있습니다.
0
280
1
주문 번호 생성 방식 관련 질문 있습니다
0
925
1
R2DBC 관련해서 질문 드립니다.
0
586
3
'더 견고해지기 위해 남은 작업' 수업자료
0
298
1
혹시 코드 리뷰 신청해도 될까요...?
0
310
1
코틀린 선택 이유
0
290
1