본문 바로가기

프로젝트40

FRONT에서의 결제 + 결제 정보 저장 현재까지 수 없이 고민한 내용은, 결제를 어떻게 진행 할 것인가 였다. 모든 결제를 BACKEND단에서 진행하자니, 많은 정책상의 문제. 그리고 또 결제가 정상적으로 진행 되었는지 사용자에게 친화적이지 않다는 문제가 있었다. 그렇다고 FRONTEND단에서만 사용하자니, 금액에 대한 관리가 우리 서버에서 전혀 진행할 수 없는 형태가 된다. POINT만을 사용하는 결제는, 결제의 기본이 남에게 확인을 받아야한다는 것을 고려했을때, 결제가 아닐 수 도 있다. 현재 그러므로 회의끝에 내린 결론은 웹하드처럼, 포인트를 구매해서(FRONT단에서) 이 포인트로 상품을 사자! 이를 위해 , 기존에 PURCHASEJSV2로 두었던 JS단에서 가장 먼저 구매 내역을 저장하게 하였다 . @Table(name = "Payme.. 2024. 2. 22.
Portone을 활용한 수기 결제(백엔드 단에 전 권한 이임) @RestController @RequiredArgsConstructor @Slf4j public class HandWritePayController { private final WebClient webClient = WebClient.builder().baseUrl("https://api.portone.io").build(); private final String mytoken = @PostMapping("/handwritepay") public Mono HandWritePay() { MethodDto handwritemethod = new MethodDto( new CardDto (new CredentialDTO("testcard", 2026, 11) )); PaymentAmount amount = .. 2024. 2. 21.
PORTONE활용 결제부, 상품 관련 DB 추가. 상품관련 DB는 2가지 분야에서 사용될 것이다. 1. 주문을 넣는 단(프론트 단)에서, 현재 남은 상품에 따라 해당 상품을 주문할 수도, 혹은 불가능 할 수 있다. 2. 결제확인까지 완료된 이후에, 남은 상품을 변경한다. (현재 프론트 단과는 협업이 필요하기 때문에, 일단 2번을 먼저 진행하도록 하겠다) 상품 DB 추가, 결제에 따른 상품 변경 DBeaver를 활용해서, 매우 간단하게 상품의 목록을 구현하였다. 그 이후엔, 이미 생성한 product table을 mapping 하였다 @Table(name = "Product") @Entity @Getter @Setter @NoArgsConstructor @AllArgsConstructor public class Product { //getter sette.. 2024. 2. 18.
PortOne을 활용한 간단 결제단 구축 결제 정보가 요청된다. test channel이기 때문에, 금액 상관 없이 결제가 가능하다. 이와 같이, 결제가 생성된다. 고려할점 - 현재 매우매우 간단하게 제공된 툴로 JS단에서 결제를 구성했다. 이런 간단한 수준만의 결제는 결과 적으론 의미가 있을 수 있어도, 프로젝트 측면에선 의미가 약하다고 판단. 빌링키 조회 API를 활용하여 REST API로 백에게 전 권한을 위임하여 통신하는 방식으로 변경해야겠다고 생각했다. @RestController @Slf4j public class PaymentController { private final WebClient webClient; public PaymentController(WebClient.Builder webClientBuilder) { this.w.. 2024. 2. 11.
PortOne을 활용한 결제 프로그램 구축 증권 계열 it업무를 분석하며 , HTS의 결제 과정에 대해서도 분석했다. 어떠한 결제, 입금, 출금, 송금이더라도, 그 기본적인 틀이 모두 동일함을 알 수 있었다 . 1. 결제 2. 실질적인 결제 (금융권은 이 작업을 직접 진행하지만, 증권계열의 한국 거래소와의 통신을 같은 맥락으로 보았다) *결제를 직접 진행할 수 있는 기관 : (여기서 결제 프로그램을 증권,금융사는 OPEN API로 하진 않기 때문에 추가적인 일들이 필요하다) 3-1. 결제 성공시, 결제에 따른 상품 변경 반영 3-2. 결제 성공시, 결제 내역 저장 (금융 , 증권사는 OPEN API를 사용하지 않기 때문에 계좌정보 확인들도 직접 진행한다) 3-3. 결제 실패시, 모든 내역 취소 4. 응답 물품을 구매하는 프로그램의 전반적인 프로세.. 2024. 2. 11.
OPEN API/ 2차 가공, 사용자 요청 DB의 저장, OPEN API 활용 응답 저번 과정 이후로 추가할 기능은 3가지이다. 1. 사용자의 요청 정보가 DB에 저장된다. 2. 사용자에게는 OPEN API의 응답을 가공하여 , JSON 형태로 RESPONSE BODY에 저장하여 보여준다. 3. 사용자는 본인이 언제의 정보를 요청했었는지를 DB를 통해 확인할 수 있다. 1. 가장 먼저, 사용자의 REQUEST를 DB에 저장할 수 있게 ENTITY와 TABLE을 사용했다. METHOD에 대한 설명은 나중에하고, 이렇게 JPA REPOSITORY를 EXTENDS한 REPOSITORY를 생성했다 . 많은 고민을 했는데, 사용자 정보 DB저장 -> OPEN API의 RESPONSE 전달을 한 TRANSACTION으로 묶기 위해 CONTROLLER 단에서 동시 구현했다. RESPONSE ENTI.. 2024. 1. 31.
OPEN API를 사용할때 주의점 OPEN API를 사용하여 OPEN API를 사용자에게 전달할 때, 주의점이 존재한다. 일단, 내가 생각하고 있는 자동매매의 흐름은 다음과 같다 . 1. 사용자가 TYPE A, B,C를 매수 매도에 대해 설정한다(DEFAULT값이 있을 것이다.) 2. 해당 TYPE에 따라서, 프로그램에서 매수 매도 한다 . 3. 이 매수 매도 정보를 DB에 저장한다. 그렇다면, 해당 매수 매도 정보를 OPEN API에서 받아와서 사용자에게 제출해야할까? 이는 그렇지 않다. 아는 동기형 이 진행했던 프로젝트 내용을 확인해보고 물어보았다. 해당 형의 프로젝트는 서비스 프로젝트로써, 사용자가 영화를 확인하고 마음에 드는 영화를 모아놓는 형태이다. 내가 생각하기엔, 모든 영화를 OPEN API에서 받아와서 DB에 저장하고, 그.. 2024. 1. 29.
OPEN API / 활용한 공공데이터로 날씨 불러오기 가장 먼저, API의 개념을 다시 복습하자. INTERFACE란, 두개의 APPLICATION 사이에서 정보를 주고 받는, 상호작용 시의 규칙과 행위 프론트에서 REQUEST를 보내고, 백엔드에서 RESPONSE를 보내는 이러한 규칙을 의미한다. UI란, USER INTERFACE이기 때문에, 사용자가 화면과 상호작용하는 규칙과 행위를 의미한다고 볼 수 있다. RESTFUL API는 HTTP + METHOD를 활용하여 통신하는 API를 의미한다. OPEN API란? 이러한 API 형태와 약속을 공개하는 것을 의미한다. *헷갈렸던 개념인데, 내가 요청을 보내고 이러한 OPEN API내부에서 백엔드->DB->백엔드 다시 나에게 RESPONSE 하는 형태이지, OPEN API가 DB만을 제공하거나 이러한 의미.. 2024. 1. 28.
testing의 전략을 수립하자. JUNIT 5는 무엇일까? 일단 특징이 있다. 전역변수로 COUNT를 선언하고, TEST1 ,TEST2에서 COUNT를 키워도값의 증가도 이루어지지않고, 주소 또한 다르게 나온다. STATIC 변수로 COUNT를 선언하면, 값의 증가가 이루어지지만 주소는 다르게 나온다. *허나, 주의해서 사용하자. 이 의미는 곧, 테스트코드의 실행시마다 인스턴스가 만들어진다는 뜻이다. @BERFORE ALL -> 테스트 실행전 한번 실행 @BERFOREEACH -> 모든 테스트의 실행 전 마다 실행된다 @AFTEREACH-> 모든 테스트마다 실행된 후 실행된다 @AFTERALL -> 테스트 실행 후 한번 실행된다. --다양한 파라미터를 편리하게 test할 수 있다. @ParameterizedTest @ValueSourc.. 2024. 1. 21.
결합도를 낮추는 방법 결합도의 종류 : 자료 결합도 : 인터페이스가 자료요소로만 결합 스탬프 : 인터페이스로 배열 자료구조 형태 전달 제어 결합도 : 논리적인 흐름을 제외 외부 결합도 :외부 모델에서 참조한다 공유 결합도 : 공유되는 공유 데이터 영역이 있음 내용 결합도: 내용이나 내부 자료와 기능등을 참조 (정보처리기사 참조) 모듈간의 결합도는 낮고, 응집도는 높아야한다. *예시 MemberSignupSevice에서 , memberrepository,couponservice,emailservice등을 모두 주입받으면 어떡할까? + 트랜잭션으로 signup이라는 method에서 -> 1.entity 생성, 2. 회원가입 3. coupon 발급을 모두 진행하면, 트랜잭션상 문제가 발생할 수 있다. 또한, 트랜잭션으로 묶여 회원.. 2024. 1. 21.

티스토리툴바