[레벨 2] 02. 2단계 - 웹 체스

@RestController
@RequestMapping(value = "/api/rooms")
public class ChessApiController {

    private static final int DEFAULT_ROOM_ID = 0;

    private final JdbcRoomDao jdbcRoomDao;
    private final JdbcChessPieceDao jdbcChessPieceDao;

    public ChessApiController(final JdbcRoomDao jdbcRoomDao, final JdbcChessPieceDao jdbcChessPieceDao) {
        this.jdbcRoomDao = jdbcRoomDao;
        this.jdbcChessPieceDao = jdbcChessPieceDao;
    }
    ...
    @GetMapping("/{id}")
    public ResponseEntity<RoomResponse> getRoom(@PathVariable final int id) {
        RoomEntity roomEntity = getRoomEntity(id);

        return ResponseEntity.ok(new RoomResponse(roomEntity));
    }
    ...
    @PostMapping
    public ResponseEntity<Integer> createRoom(@RequestBody final RoomSaveRequest request) {
        final RoomEntity roomEntity = new RoomEntity(DEFAULT_ROOM_ID, request.getName(), request.getPassword(),
                GameStatus.READY.getValue(), Color.WHITE.getValue());

        final int id = jdbcRoomDao.save(roomEntity);

        return ResponseEntity.created(URI.create("/api/rooms/" + id)).body(id);
    }
    ...
    @PatchMapping("/{id}/pieces")
    public ResponseEntity<MoveResult> movePiece(@PathVariable final int id,
                                                @RequestBody final ChessPieceMoveRequest request) {
        final RoomEntity roomEntity = getRoomEntity(id);
        final ChessGame chessGame = getChessGame(roomEntity);

        final Position from = Position.from(request.getFrom());
        final Position to = Position.from(request.getTo());

        final MoveResult moveResult = chessGame.move(from, to);

        jdbcChessPieceDao.deleteByRoomIdAndPosition(roomEntity.getId(), request.getTo());
        jdbcChessPieceDao.update(roomEntity.getId(), request.getFrom(), request.getTo());

        jdbcRoomDao.update(new RoomEntity(roomEntity.getId(), roomEntity.getName(), roomEntity.getPassword(),
                moveResult.getGameStatus().getValue(), moveResult.getCurrentTurn().getValue()));

        return ResponseEntity.ok(moveResult);
    }
    ...
}

`리뷰어`: 서비스를 제거한 이유가 있을까요??

`매트`: 이전 서비스는 단순히 controller가 위임을 하기 위한 목적 뿐이라고 판단하였습니다. 이번에 Dao와 Controller를 전면적으로 개편하며 Service layer에 대한 필요성을 잘 느끼지 못해서 해당 클래스는 제거하였습니다!

이미 도메인 객체가 비즈니스 로직을 가지고 있기 때문에 추가적인 Service layer를 통한 계층 분리는 불필요 하다고 판단하였습니다. 로운이 생각했을 때 service layer를 분리하기 위한 목적은 무엇인가요? 저는 아직 계층 분리를 위한 근거의 기준이 잡히지 않아 질문드립니다!

`리뷰어`: `Service의 역할`을 생각해보면 될텐데요.

기존에는 controller만 있었고, 매트처럼 controller에서 request 검증, domain에 요청, dao에 요청, response 응답 생성 등을 다 맡아서 진행했을 겁니다. 이러다 보니 controller의 역할이 너무 커지게 되었고, 로직을 파악하는 어려움이 생겼을 거라고 생각해요.
그래서 service에 비지니스 로직을 위임하고, controller에서는 비지니스 로직 이외의 request 검증, response 응답 생성 등만 맡아서 하는 형식으로 바뀌지 않았을까 생각합니다.

현재 controller의 movePiece를 보면 체스가 작은 프로그램인데도 생각보다 코드량이 많다는 것을 알 수 있어요.
그렇다면 체스보다 훨씬 큰 프로그램의 경우에는 어떻게 될 수 있을까요? 그리고 service는 큰의미의 도메인 service가 생기게 되는데 어느 도메인에서 에러가 발생했을 경우에 파악을 하는 데에도 더 빠르게 파악할 수 있지 않을까요?

예를 들어 주문과 배달 도메인이 있는데 주문 프로세스로 a 도메인 로직이 돈 후 b 도메인 로직을 돌고 c에 요청해서 데이터를 가져와야 하고 배달도 비슷한 순서의 로직을 돈다고 한다면 orderService와 deliveryService로 나뉘어져 있어야 각각의 로직의 흐름을 파악하고 도메인에 에러가 났을 때 어디를 봐야할 지 명확하지 않을까요??
저는 우리가 도메인의 역할과 책임을 생각하고 그에 따라 확인해야 하는 위치를 파악했던 것이 service에도 동일하게 적용된다고 생각합니다~

개인적으로 현재의 수준에서는 저도 매트처럼 service가 없어도 괜찮다고 생각합니다~ service를 쓴다고 했을 때 response dto로의 변환을 controller에서 할지 service에서 할지에 대해서도 한번 고민해보시면 좋을 것 같아요~
그리고 service를 쓴다고 하면 service가 주요 `비지니스 로직을 담당`하기 때문에 `테스트는 꼭 만들어 주는 것`이 좋습니다.

@RestController
@RequestMapping(value = "/api/rooms")
public class ChessApiController {
    ...
    @PatchMapping("/{id}/pieces")
    public ResponseEntity<MoveResult> movePiece(@PathVariable final int id,
                                                @RequestBody final ChessPieceMoveRequest request) {
        final RoomEntity roomEntity = getRoomEntity(id);
        final ChessGame chessGame = getChessGame(roomEntity);

        final Position from = Position.from(request.getFrom());
        final Position to = Position.from(request.getTo());

        final MoveResult moveResult = chessGame.move(from, to);

        jdbcChessPieceDao.deleteByRoomIdAndPosition(roomEntity.getId(), request.getTo());
        jdbcChessPieceDao.update(roomEntity.getId(), request.getFrom(), request.getTo());

        jdbcRoomDao.update(new RoomEntity(roomEntity.getId(), roomEntity.getName(), roomEntity.getPassword(),
                moveResult.getGameStatus().getValue(), moveResult.getCurrentTurn().getValue()));

        return ResponseEntity.ok(moveResult);
    }
    ...
}

@RestController
@RequestMapping(value = "/api/rooms")
public class ChessApiController {
    ...
    @PatchMapping("/{id}/pieces")
    public ResponseEntity<MoveResult> movePiece(@PathVariable final int id,
                                                @RequestBody final ChessPieceMoveRequest request) {

        final MoveResult moveResult = chessService.move(id, request.getFrom(), request.getTo())
        return ResponseEntity.ok(moveResult);
    }
    ...
}

@Repository
public class JdbcRoomDao {
    ...
    public void deleteAll() {
        final String sql = "DELETE FROM room";
        jdbcTemplate.update(sql);
    }
}

@SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)
class ChessApiControllerTest {
    ...
    @BeforeEach
    void setUp() {
        RestAssured.port = port;
    }

    @AfterEach
    void tearDown() {
        roomDao.deleteAll();
    }
    ...
}

`리뷰어`: jpa 같은 경우에 deleteAll은 기본적을 제공하는 메서드입니다.

그래서 저는 개인적으로 괜찮다고 생각하는데요. 다만 테스트만을 위한 메서드를 운영 코드에 만드는 것은 좋지 않다는 것에는 저도 공감하고 있기 때문에 그 부분이 불편하다면 `test에서 jdbcTemplate를 사용해서 삭제`하도록 하는것도 방법일 것 같습니다!

@SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)
class ChessApiControllerTest {
    ...
    private final JdbcTemplate;

    @Autowired
    public ChessApiControllerTest(final JdbcTemplate jdbcTemplate) {
        this.jdbcTemplate = jdbcTemplate;
    }
    ...
    @AfterEach
    void tearDown() {
        final String sql = "DELETE FROM room";
        jdbcTemplate.update(sql);
    }
    ...
}

`리뷰어`: 저는 @BeforeAll을 생각했는데 생성자를 만들어서도 사용할 수 있군요! 👍
@Autowired부분은 저도 그냥 자연스럽게 쓰고 있던 부분이랑 이번에 찾아보게 되었는데요. 

에러가 발생하는 이유는 Junit5가 DI를 스스로 지원하고, DI를 지원하는 타입이 정해져 있다고 하네요.

Junit5에서 생성자나 lombok방식으로 DI가 안되는 이유는 Junit이 생성자에 다른 의존성을 주입하려고 먼저 개입하기 때문이라고 합니다.