-
리팩토링 5. 속도 향상 목표 + 예외처리 현재 결제 로직은 다음과 같다. 어떤 서비스가 가장 오래 걸리는가 즉, 현재 결제 이후 결제 문제가 생겨 이를 취소하는 과정이 가장 큰 시간을,혹은 결제와 구매정보 변동까지 되어 이를 저장하는 과정이 두번째로 큰 시간을 사용함을 알 수 있었다. *의외로, MSA구조에 따른 MINISERVICE간의 통신엔 큰 시간이 소요되지 않았다. 로직의 속도 증가가 더 큰 로직을 더 좋게 만들어보자 1. 결제가 잘못되어 취소를 보내야 할때public Mono validateandSave ( PortOnePaymentRecords portOnePaymentRecords, String paymentId, int frontPaymentClaim, String usere..
-
리팩토링 4 - WEBFLUX 이번 프로젝트에 참여하기 전에, 개인적으로 결제 시스템의 핵심은 비동기라고 판단했다. 하여 결제에 대한 부분을 비동기적인 형태로 완성했다. 하지만 리팩토링을 하면서 보니, 비동기적인 통신 형태에 대해 조금 더 명확하게정리하고 이를 비동기적으로 설계하면 어땠을까 라는 아쉬움이 있었다. WEB FLUX VS MVC? 먼저, WEBFLUX와 MVC 패턴에 대한 예시를 보아야 한다. 이와 같이, WEB FLUX와 MVC는 아키택처부터 다르다. MVC는 MODEL -VIEW- CONTROLLER 아키택처를 따른다.이는 현재 가장 많이 상용화된 아키택처로써, 서브 시스템을 호출하고 해당 시스템에MODEL이라는 정보를 전달, VIEW는 그것을 표현하는 시스템이다. 하지만 WEBFLUX는, 아키택처부터 다른..
-
리팩토링 3 - JPA 추상층 변경 JPA 현재 문제 이와 같이 , 기본적인 기능만 (따로 선언하지 않아도 되는) 사용하는 JPAREPOSITORY에 대한 리뷰를 받았다. 왜 이런 형태는 단점이 있을까? JPA의 구조: JPAREPOSITORY를 사용한다는 건, 영속성 컨텍스트를 이해 해야 한다. 영속성 컨텍스트 (PERSISTENCE CONTEXT): ENTITY를 영구 저장하는 환경 APPLICATION과 , DATABASE 사이에서 객체를 저장하는 가상의 DB가된다. (키:밸류 형태의 해시를 활용해, 조금 더 빠르게 사용하게 돕는다) FLUSH를 통해 실제 DB에 저장한다. ENTITY MANAGER: 이 영속성 컨텍스트를 관리한다. 엔티티를 저장하고 관리한다. 고민 JPAREPOSITORY를 활용한다는 건, 수많은 기능과 영속성 컨..
-
리팩토링 2 - 결제 검증과, XSS 등에 대한 방어 테스트 개인적으로 생각했던, 결제의 핵심은 검증과 검사였다. 여러가지 경우에 대해 방어 테스트를 진행했었지만, 리팩토링 과정에서 추가하고자 했던 검증 과정등을 정리하여보겠다. 현재 결제 과정은 1. member에 결제 요청 -> 2. 사용자 포인트가 결제 금액보다 작은지 검증 -> 3. 작다면, 그만큼 다시 front end로 전달-> 4. front end에선, 그 부족한 금액만큼 결제 진행 -> 5. 그 결제 금액을 검증받고, 저장, 승인 -> 6. purchase 부에서 다시 member 부로 전달(product의 상태 변경, 사용자 포인트 변경 등 수행) 1. 1000원을 결제하고, 100000포인트를 넣어달라는 악의적인 요청 이러한 경우는 JSON BODY로 악의적인 DATA를 전송하였거나,혹은 코드..
-
코드 리팩토링 1 - 코드 정리, 가독성 증가 구조 정리 1. 수 많은 dto들의 위치를 정리하였다. 현재 우리의 프로젝트는 MSA 구조이기 때문에, 서로의 동작을 약속하고 개발 과정은 완전히 독립적이다. 남이 보기에도 명확하게, 한눈에 보기 쉽게 DTO를 정리하였다. 2. SERVICE가 아닌 METHOD 단위의 분할을 진행하였다. 설계 과정에서 SERVICE의 범위를 최대한 세밀하게 분리하자는 생각에 따라 각 SERVICㄷ들이 1개의 메소드를 지니게 아주 잘게 서비스를 분할하였는데, 리팩토링 과정에서 해당 과정에 따른 높은 결합도의 문제에 대한 의견을 들었다. 전체적인 결제의 검증과 저장을 한 SERVICE로 묶었다. 해당 SERVICE들은 사실 메소드의 개수가 많지 않기 때문에 분할하여도 되었지만, 서비스의 범위 자체가 요청을 보내는 부 , 요..