최근, 컴포트 존에 들어와서 익숙한데로 업무를 진행하려고 하는 경향을 갖게 된 것 같다.현재 회사에서는 올바른 성장 롤모델을 보여줄 사수나 시니어는 없는 상황이라, 지금처럼 업무만 진행한다면, 좋은 개발자가 되기는 어려울 것 같다는 생각이 들었다. 현재, 개발에서는 도메인 주도 개발이 유행하고 실제로 많은 회사들이 이 DDD를 우대사항으로 내거는 회사들이 많은데, 습관적으로 개발을 해왔던 나로서는 왜 DDD가 유행이고 중요한지 전혀 알길이 없었다. 그래서, 이번에 블로그 글을 정리하여 습관적으로 작성한 코드안에 녹아있는 도메인과 아키텍처의 내용을 정리하고, 앞으로의 학습 방향을 확고히 하고자 한다.누구나 잘 알면서 잘 모르는 도메인혹시 '코끼리와 시각장애인'이라는 이야기를 알고 있는가?이야기를 대략 요약..

개요 현재 Payment-lab에서 가장 큰 고민은 결제 승인 데이터의 손실을 최소화하는 것입니다. payment-lab에서는 사용자의 결제 승인 데이터의 정합성을 최대한 맞추기 위해, 무조건 PG api의 결제 승인 요청이 성공한 다음에 해당 로그를 DB에 기록하는 방식을 채택하고 있습니다. CA(Consistency, Availablilty)를 최대한 보장하기 위해 결제 승인 프로세스는 동기 방식으로 진행하기에 실제로 결제가 수행되는 시간이 지연될 수 있습니다. 결제 알림의 경우, 사실 결제 승인이 실제로 이루어지기 이전 시점에 수행한다면 사용자의 편의성을 침해하는 경우를 방지할 수 있을 것입니다. PG사의 결제 서비스 자체가 실패하는 경우는 드물고, MySQL과 같은 관계형 데이터베이스는 일관성과 ..

이 게시글은 payment-lab이라고 하는 결제모듈 연동 사이드프로젝트를 진행하던 중 발생한 기술적 이슈를 해결하기 위해 정리하는 글입니다. 스프링 프레임워크에는 로깅을 직관적으로 사용하도록 도와주는 Log 관련 라이브러리들이 있습니다. 구체적으로는 log4j, logback 등을 사용하지만 스프링에서는 ‘slf4j’ 로그 통합 인터페이스를 제공하는 라이브러리를 통해 로깅을 합니다. payment-lab 에서는 로그를 단순히 애플리케이션의 동작 이력 및 디버깅 참고용으로 기록하는 것을 넘어서, 결제 정산 및 백업 그리고 복구를 수행하는데 활용됩니다. 그래서 처음에는 logback 설정을 통해 별도의 로거를 생성하여 결제 이력을 기록했습니다. logback-spring.xml logs/applicatio..

이 게시글은 payment-lab이라고 하는 결제모듈 연동 사이드프로젝트를 진행하던 중 발생한 기술적 이슈를 해결하기 위해 정리하는 글입니다. 결제 모듈을 개발하던 중 한가지 고민에 빠졌습니다.. 바로 사용자가 실수로 중복 결제(일명 따닥이)를 하게될 경우 어떻게 대비할지에 대한 고민이죠. 현재 진행하는 프로젝트는 토스페이먼츠로 결제 연동을 수행하고 있습니다. 토스페이먼츠의 경우 이러한 중복 결제 혹은 취소를 방지하기 위해 멱등키를 제공하고 있습니다. 이러한 멱등키를 적용하는 것은 너무나도 당연합니다. 그러나 그 멱등키를 어떻게 생성해야할까요? 만약 그냥 결제 요청마다 무작위의 uuid로 적용한다면 무슨일이 일어날까요? 사실상 멱등키를 적용하나마나일겁니다. 어차피 결제 요청 한번 할때마다 유일한 멱등키를..

회원가입은 기능을 구현하는 것 자체는 매우 간단합니다. 그러나, 회원가입을 안전하게 수행하는 방법을 적용하여 보안을 강화하고자 한다면 그 기능은 점점 더 어려워집니다. 회원가입을 안전하게 수행하는 방법은 여러 가지가 있지만, 저는 그중에서 회원가입 과정에서 로깅을 수행할 때 비밀번호가 노출되었을 때의 위험성과 그 대응방안을 모색하고자 합니다. 먼저 문제가 발생할 수 있는 코드부터 보여드리겠습니다. class AccountRegister( private val accountRepository: AccountRepository, private val encrypt: PasswordEncrypt ) { fun register(email: String, password: String, username: Stri..

결제 api를 작업하던 중 결제 상태를 변경해야하는 상황이 생겼습니다. 물론 현재는 결제 서비스를 제공하는 것보다는 정확한 정산에 집중하고 있기 때문에 아직은 크리티컬하진 않지만 결제 서비스가 진행되는 중에 수행해야하는 결제 상태 변경을 소홀히 한다면 결제 정산을 하는 의미가 없기 때문에, 아직은 급하지 않은 지금 더 제대로 파고들어 근본적인 해결을 수행하고자 합니다. State Machine State machine은 Java가 태어나기 훨씬 이전부터 나온 개념입니다. State machine은 1943년 Warren McCulloch와 Walter Pitts에 의해 소개된 논문에서 나왔습니다. 이러한 개념이 생긴 이후로 Mealy Machine과 Moore Machine이 소개되었습니다. State ..