<aside> 1️⃣ 2가지의 관점설명

</aside>

• Web 요청을 처리할 때 2가지 관점이 존재한다.
  1. Controller에서 Request Dto를 받아서 그대로 Service에 전달하여 Service에서 사용한다.
  2. Service 코드에서 사용할 서비스코드 전용 Request를 받아줄 Dto를 따로 만들고, Controller에서는 Request Dto를 Service에서 사용할 전용 Request Dto로 변환 후 전달하여 사용한다.
• 2번 방법을 적용시키는 이유
  1. View에 Service가 종속적이게 된다.
  2. View의 요청 정보가 변경되면 Service 계층까지 영향을 줄 수 있다.
  3. 그래서, Controller와 Service가 강한 의존을 가질 수 있다.
  4. Controller에서 원하는 포맷과 Service에서 원하는 포맷이 다르다.
     • 예시 상황으로는 외부 API가 컨트롤러 단에 존재할 때, Web에서 들어온 Request Dto와 외부 API 호출 후에 Service로 전달될 Dto의 포맷이 달라진다는 상황이다.

<aside> 2️⃣ 2번 방법에 대한 내 생각

</aside>

• 내가 생각했을때는 Controller에서 Service로 Request Dto를 그대로 전달하는 방식을 그대로 사용하고 정말 포맷이 바뀌거나 그런상황이 발생했을때 커스텀 dto를 만들어서 서비스에 보내는게 좋지 않을까 생각된다. 그런데 이렇게 하면 전체적인 통일성이 깨져버릴까봐 고민이긴 하다.. 그냥 한가지 방식을 고수하는게 좋을것같은데 좀 많이 생각해봐야할 문제인것같다.

<aside> 3️⃣ Request를 받아서 그걸로 바로 내부 로직을 처리하는 방식

</aside>

1. Request를 바로 받아서 내부 로직을 수행

@PostMapping
public ResponseEntity<UserSaveResponse> createUser(@RequestBody UserRequest userRequest) {
    UserSaveResponse userSaveResponse = userService.saveUser(userRequest);
    ...
}

1. 이때 서비스는 이렇게 적용되었다.

public UserSaveResponse saveUser(UserRequest userRequest) {
	
    // userRequest 사용하여 비즈니스 로직 수행
    ...
}

1. 위의 코드를 UserCommand라는 dto를 따로 만들어서 서비스에서 사용하도록 개선했다.

@PostMapping
public ResponseEntity<UserSaveResponse> createUser(@RequestBody UserRequest userRequest) {

	  // UserRequest를 UserCommand dto 클래스로 변환한다.
    UserCommand userCommand = userRequest.toCommand(...);
    UserSaveResponse userSaveResponse = userService.saveUser(userCommand);
    ...
}

• UserCommand를 사용하도록 변형시킨 서비스 로직이다.

public UserSaveResponse saveUser(UserCommand userCommand) {
	
    // UserCommand를 사용하여 비즈니스 로직을 수행한다.
    ...

}

<aside> 4️⃣ 출처

</aside>

• 공부 출처: https://ksh-coding.tistory.com/102