[필수 과제1] 클래스 다이어그램

[kimjuls]

시간이 얼마 안 남아 뭐라도 올려보고 싶어 미완이지만 올립니다.

• Repository-pattern의 3-Tier Layered Architecture로 전체 프로젝트를 구성하였습니다.

• 구현 기능은 결제 승인과 결제 취소입니다.

• JPA Entity로 Payment를 정의해보았습니다. 결제 승인 이후 취소가 가능하도록 Toss의 paymentKey, NHN의 tno를 uniquePaymentKey(고유거래/결제번호)에 저장을 유도합니다.

• 실무에서도 자주 사용하던 방법인데 저장해왔던 공통 데이터 외 필드가 추가될 때, 과거 데이터를 추적하기 위해 rawObject를 Entity에 추가로 그대로 저장합니다. MySQL 데이터타입을 예시로 한다면 Text 혹은 JSON 타입을 쓸 수 있고, 가능하다면 DynamoDB나 MongoDB를 이용하여 NoSQL을 사용할 수 있을 것입니다.

• PG사들에 대한 객체 지향 설계는 PaymentGateway 인터페이스 + Factory 패턴을 사용하였습니다. 여러 참여자들이 올려둔 이슈도 참고하고 Strategy 패턴도 생각해봤지만 Strategy 패턴보다는 런타임 중에 Enum 패러미터를 통해 동적으로 변경할 수 있는 Factory 패턴이 가장 적합하다고 생각했습니다.

• 승인, 취소 API에 대한 요청, 응답 데이터의 공통화를 위해 추가로 고민 중입니다. 사실 전체 아키텍처보다 이 부분이 가장 어렵고 중요한 부분일거라 생각합니다.

[jinho-yoo-jack]

@kimjuls 고생하셨습니다!!! 추상적으로 잘 구성해주신 것 같아요. 변경 유연하게 대응할 수 있도록? 그런데 6번째로 질문 주셨던 것 처럼(승인, 취소 API에 대한 요청, 응답 데이터의 공통화를 위해 추가로 고민 중입니다. 사실 전체 아키텍처보다 이 부분이 가장 어렵고 중요한 부분일거라 생각합니다.) requestDTO/responseDTO를 어떻게 풀어가냐가 중요한데, 그 부분 말고는 다 괜찮은 것 같습니다.

제네릭 또는 상속, 람다, 레플릭션을 이용하면 고민하고 있는 공통화 문제를 조금 손쉽게 해결할 수 있지 않을까? 라는 생각이 듭니다. 또는 공통화를 버린다?라는 조건으로 생각해보면 또 어떨까요?

[kimjuls]

고민 중인 부분은 각 PG사별로 상이한 Request/Response 타입을 결제승인/취소에서 적용하기위해 제네릭을 사용하는것을 고려하고 있었는데, 공통화를 포기한다는 것은 이 의미로 이해됩니다.

한편 결제 승인 내역을 DB에 기록할 시에는 결국 정규화가 필요하므로, 각 승인 응답을 공통화하여 공통타입의 RepositoryDTO를 반환하는 PG사 인터페이스 구현체별 parsing 메서드(인터페이스 내에서도 정의 필요)가 필요할 것으로 보입니다. 서비스 레이어에서 이 메서드를 거쳐 반환된 RepositoryDTO를 Repository Create 메서드에 인자로 사용하는 쪽으로 생각되네요.

예상치 못한 빠른 피드백으로 한층 더 이해가 된 느낌입니다. 감사합니다.

이따 19시에 뵙겠습니다!