인프런 커뮤니티 질문&답변

1. 클라이언트로부터 전달되는 presentation layer 에서 바로 전달받는 것을 기대하셨는지

2. 아니면 리팩토링 전과 같이 payRequest 로 controller에서 전달 받은 뒤 다른 layer (business 혹은 presentation) 에서 dto 로 변경한 뒤 businessPay() 메서드를 호출하여 인자를 입력해주는 것을 기대하셨는지

3. 아니면 다른 방법으로 진행이 되는지

2번입니다!

PayRequest 가 Presentation Layer 에 있는 상황에서, Business, Implement Layer 에 파라미터로 넘어온다는 것 자체가 레이어를 지키는 규칙을 위반하는 '레이어 역류' 에 해당 되버리기 때문입니다.

그래서 흐름 상으로 보면 외부 랑 가장 가까운 Presentation Layer 에서 PayRequest 를 받고 Presentation Layer 에서 Business Layer 로 가기전에 Business, Implement Layer 의 객체로 변환을 하고 넘겨준다고 이해하시면 될 것 같습니다.

제 유튜브에도 있을 것 같은데 저도 못 찾겠네요;; 관련해서는 예전에 제가 발표했던 내용을 참고해 보시면 좋을 것 같습니다!

https://youtu.be/RVO02Z1dLF8?si=Wj4ZhsYESDE2T5xS&t=508

질문 감사드립니다!

안녕하세요, 인프런 AI 인턴입니다.

리팩토링 전과 후의 코드를 분석해보면, 비즈니스 로직 처리 방식에 있어서 명확한 차이가 있습니다.

1. 리팩터링 전 코드는 PayRequest와 userId를 직접 인자로 받아 처리하는 방식이었습니다. 이 경우, presentation layer에서 직접 PayRequest 형태로 데이터를 전달받아 비즈니스 로직에 적용하는 구조였습니다.

2. 리팩터링 후 코드에서는 targetStore, usePoint, userId를 직접 인자로 받아 처리하고 있습니다. 이는 각 요소를 별도의 객체로 관리하면서 더 명확하게 역할을 분리하고자 하는 의도로 볼 수 있습니다. 또한, targetStore와 usePoint는 새롭게 정의된 객체로, 비즈니스 로직을 처리하기 위해 필요한 정보를 명확히 표현합니다.

이로부터 추정할 때, 리팩토링 후의 접근 방식은 클라이언트로부터 전달되는 데이터를 presentation layer에서 받은 후, 필요한 정보를 추출하여 targetStore, usePoint 등의 객체로 변환하는 과정을 거치는 것으로 보입니다. 즉, 두 번째로 언급하신 방식, 즉 payRequest를 controller에서 받은 후, 다른 layer에서 필요한 객체로 변환하여 businessPay() 메서드에 인자를 전달하는 방식을 기대한 것으로 보입니다.

이는 각 계층의 책임을 더 명확히 하고, 비즈니스 로직 처리에 필요한 정보를 더 직관적으로 관리하기 위한 목적으로 해석할 수 있습니다. 따라서, 새롭게 나오게 된 targetStore, usePoint 객체들은 리팩터링을 통해 보다 체계적이고 명확한 비즈니스 로직 처리를 가능하게 하는 요소로 도입된 것입니다.