posts/payment-system-architecture/

[giscus[bot]]

posts/payment-system-architecture/

"만약 내일 당장 '프랑스'가 서비스 국가로 추가된다면? 그리고 한국에서 '사업자 유형'에 따라 결제 수단이 달라져야 한다면?" 이 질문들이 우리 팀의 결제 시스템 설계를 완전히 바꿔놓았습니다. --- 🎭 Prologue: "팀장님의 무리한(?) 요구" 어느 날 오후, 코드 리뷰 중에...

https://blog.sangwook.dev/posts/payment-system-architecture/

[prgmr99]

좋은 글 감사합니다 :)
저도 결제 시스템 쪽 로직이 꽤 지저분해서 리팩토링이 필요했는데, 많은 인사이트를 배운 것 같아요!

성공적으로 리팩토링을 완료하게 되면 저도 경험을 공유하러 찾아오겠습니다 🙇‍♂️

[Han5991]

읽어주셔서 감사합니다!

[YoonHan]

글 정말 잘 읽었습니다! 평소에는 코드 depth가 늘어나는게 코드를 읽기 힘들게 만든다고 생각해서 디자인 패턴을 웬만하면 적용안하려고 하는데, 마주하신 상황에서는 cons보다 pros가 훨씬 크네요 :)

설명해주신 로직에서 한 가지 질문이 있는데,
단일 hook 내부의 requestPayment 함수에서 한 번 더 비즈니스 로직 검증을 해주는 특별한 이유가 있을까요?
Factory의 getAvailableProviders 메서드 내부에서 이미 context에 맞는 payment provider를 골라서 리턴해주고 있는데, 다시 한 번 체크 해주는 이유가 궁금했어요!

[Han5991]

앗! 놓친 부분 잡아주셔서 감사합니다. 말씀대로 한번 더 할 필요는 없을 것 같아요

작성할 당시에는 하나씩 꼼꼼하게 조립 해가면서 만드느라 한번 더 검증 로직이 들어 갔네요.
잠시 생각을 해보자면 검증 로직은 비즈니스 로직에서 검증 해주는게 좋을 것 같아요.

Factory는 생성만 할 수 있게요!