[우테코 5기] 웹 자동차 경주 미션 회고

두둠과 진행한 레벨 2 첫 페어 프로그래밍 미션인 웹 자동차 경주 미션이다 :D

어쩌다 보니 1등으로 레벨 2 첫 미션을 마무리하게 되었다 👏

 

레벨 2의 목표는 미션에 대한 회고글이 밀리지 않는 것이기 때문에, 빠르게 회고 글을 작성해보고자 한다.

이번 미션은 요구사항에 비해 미션 기간이 길었기 때문에, 미션을 여유롭게 진행할 수 있었다.

남은 기간 동안에는 스프링에 대해서 좀 공부해보는 시기로 가져보려고 한다.

---

✔️ 작성한 코드

GitHub - Cl8D/jwp-racingcar: 레벨 2 자동차 경주 게임 웹 구현 저장소

- PR 제출 이후 조금 더 수정한 부분이 있어서 아마 2차 PR의 마지막 부분과 조금 다릅니다!

 

✔️ 1차 PR

[1단계 - 웹 자동차 경주] 져니(이지원) 미션 제출합니다. by Cl8D · Pull Request #61 · woowacourse/jwp-racing

 

✔️ 2차 PR

[2단계 - 웹 자동차 경주] 져니(이지원) 미션 제출합니다. by Cl8D · Pull Request #99 · woowacourse/jwp-racing

 

---

✔️ 기능 요구사항

- 자동차 경주 코드 가져오기 (레벨 1 때 진행했던 코드 가져오기)

- 웹 요청/응답 구현하기

: 웹을 통해 게임을 플레이 할 수 있도록 구현하세요.

 

Request

POST /plays HTTP/1.1
content-type: application/json; charset=UTF-8
host: localhost:8080

{
    "names": "브리,토미,브라운",
    "count": 10
}

Response

HTTP/1.1 200 
Content-Type: application/json

{
    "winners": "브리",
    "racingCars": [
        {
            "name": "브리",
            "position": 9
        },
        {
            "name": "토미",
            "position": 7
        },
        {
            "name": "브라운",
            "position": 3
        },
    ]
}

 

- DB 연동하기 (H2 DB 연동)
DB에 저장되는 정보는 다음과 같습니다.
: 플레이 횟수(trialCount)
: 플레이어 별 최종 이동 거리 (이름(name), 최종 위치(position))
: 우승자(winners)
: 플레이한 날짜/시간

 

- 게임 플레이 이력 조회 API 구현

: web application에서 DB에 저장된 플레이 이력을 요청하면 응답하는 기능을 구현합니다.

HTTP/1.1 200 
Content-Type: application/json

[
    {
        "winners": "브리",
        "racingCars": [
            {
                "name": "브리",
                "position": 6
            },
            {
                "name": "토미",
                "position": 4
            },
            {
                "name": "브라운",
                "position": 3
            },
        ]
    },
    {
        "winners": "브리,토미,브라운",
        "racingCars": [
            {
                "name": "브리",
                "position": 6
            },
            {
                "name": "토미",
                "position": 6
            },
            {
                "name": "브라운",
                "position": 6
            },
        ]
    }
]

---

이번에는 많은 이야기를 나눈 게 아니었어서, 앞으로 고민할 부분과 고민했던 부분에 대해 정리해보고자 한다.

 

💬 오류가 발생하면 alert 해주기

사실 이거는 html 관련이지만, 두둠이랑 이거 하려고 30분 정도는 삽질했던 것 같아서 적어둔다.

기존의 html 스펙에서는 오류가 발생하더라도 내부 콘솔에서만 400 에러가 발생하고, 아무런 일도 발생하지 않았다.

하지만 뭔가 사용자 입장에서는 오류가 발생했을 때 뭔가 나타났으면 좋겠어서, alert 기능을 추가하였다.

이런 식으로 오류 발생 시 알림이 간다.

fetch("/plays", {
            method: "POST",
            headers: {
                "Content-Type": "application/json;charset=UTF-8"
            },
            body: JSON.stringify(data)
        })
            ...
            .catch(error => {
                window.alert(JSON.parse(error.message).message);
                console.error("Error:", error);
            });

그냥 아래처럼 에러 메시지를 꺼낸 다음에 (JSON.parse를 통해 json 형태로 내려온 값에서 꺼내는 것) alert 해주면 된다.

 

---

💬 도메인에서 관리하는 예외 메시지를 그대로 뷰에 노출시켜도 되는가?

레벨 1 미션에서는 '오류 메시지를 발생한 지점에서 관리해야 한다' 라는 것에 초점을 맞추다 보니, 콘솔의 뷰에 예외 메시지가 출력되어도 그렇게 신경쓰지 않았다. 하지만, 이번에는 웹인 상황이고 html에서 오류가 발생하면 사용자에게 노출되는 메시지가 도메인에서 관리되는 것과 동일해진다.

만약 다국어 기능을 추가한다면? 혹은, view에 따라 다른 문구를 출력해야 한다면?

도메인에서 관리하는 것보다 다른 외부에서 관리하도록 하는 것이 좋을 것이다.

 

기존의 코드이다.

@ExceptionHandler(IllegalArgumentException.class)
public ResponseEntity<ExceptionDto> handleIllegalArgumentException(final IllegalArgumentException exception) {
    final ExceptionDto exceptionDto = new ExceptionDto(exception.getMessage());
    return ResponseEntity.status(HttpStatus.BAD_REQUEST).body(exceptionDto);
}

도메인에서 발생되는 IllegalArgumentException에 담긴 message를 꺼내와서 response body로 넣어주었다.

그리고 각 도메인에서는 다음과 같이 오류를 발생시켰었다.

private void validateDuplicateCarName() {
    int uniqueCarCount = new HashSet<>(cars).size();
    if (cars.size() != uniqueCarCount) {
        throw new DuplicateException(DUPLICATE_MESSAGE);
    }
}

 

이걸 어떤 식으로 해결할 수 있을까 고민하다가 2가지 방법을 고안했다.

1. 도메인마다 각각 다른 예외를 발생시켜서 ExceptionHandler에서 예외 상황에 맞게 처리하기.
2. 예외는 동일하게 두되, enum을 통한 ErrorCode를 사용하여 관리하기

처음에는 2번 방식을 사용할까 고민하다가, ErrorCode의 경우 400, 404 외의 커스텀 상태 코드를 만드는 것과 비슷하다고 생각했고 (개인적인 생각), 현재는 사용자의 잘못된 입력 값에 대해서 처리하는 것이기 때문에 상태 코드 쪽과는 관련있게 하고 싶지 않았다.

미션이 종료된 지금 생각해보면, 그냥 ErrorCode라는 이름 대신에 다른 객체를 enum으로 두고, 내부에서 메시지를 변수로 관리해서 ExceptionHandler에서는 해당 객체에 담긴 메시지를 출력하도록 해도 되지 않았을까 싶다.

 

우선, 기본적으로 넘어온 값이 null이거나 비어있는 것에 대한 체크는 Request DTO에게 책임을 넘겼다.

public class RaceRequest {

    @NotBlank(message = "자동차 이름은 비어있을 수 없습니다.")
    private final String names;

    @NotNull(message = "경주 횟수는 비어있을 수 없습니다.")
    private final int count;

    ...
}

DTO는 뷰에서 받아온 데이터를 넘겨주는 역할이기 때문에 message를 관리해도 상관없다고 생각하였고,

도메인에서는 순수하게 완전한 값을 받는 것이 맞다고 생각했기 때문에 validation annotation을 통하여 관리했다.

 

그외의 커스텀 예외는 다음과 같이 진행하였다.

public class ErrorData<T> {
    private final T data;

    public ErrorData(final T data) {
        this.data = data;
    }

    public T getData() {
        return data;
    }
}

우선, ErrorData라는 객체를 만들었다. 이는 도메인별로 다른 제한 조건을 예외 메시지에 유동적으로 담기 위해서 만들었다.

private void validateRange(final int raceCount) {
    if (raceCount <= MIN_RACE_COUNT) {
        throw new ResourceMinRangeException(new ErrorData<>(MIN_RACE_COUNT));
    }
}

그리고 다음과 같이 예외를 검증하였다. 이는 입력으로 들어온 경주 횟수가 최소 횟수 이하인지 검증하는 부분이다.

인자로 도메인의 규칙인 '0번 이하'의 값을 담는 MIN_RACE_COUNT를 담았다.

 

물론 @Range 어노테이션을 사용해도 되지만, 나는 다음과 같은 이유로 사용하지 않았다.

1. raceCount가 0 이하라는 값은 도메인 자체의 규칙이라는 생각이 들었다.

(만약 요구사항이 변경되어서 경주 횟수는 최소 5번부터 받아야 한다면?)

2. 도메인에서 @Range를 통해 인자로 message를 넘기면 결국 뷰에 보여질 값을 또 다시 도메인에서 관리하는 것 같았다.

 

🌱 이 부분에 대해서는 리뷰어님이 의견을 남겨주셨어서 메모해두고자 한다.

- Presentation Layer에서 검증되어야 하는 부분과 도메인에서 검증되어야 하는 부분이 있다.
도메인은 일반적으로 모든 클라이언트에게 적용되어야 하는 공통적인 '도메인 규칙'이고, 클라이언트에 따라서 적용되어야 하는 규칙은 도메인에 있으면 안 된다. (특정한 view를 의존해서 안 되기 때문이다)

그래서 예를 들어보자면, '자동차 이름이 10자 이내여야 한다'라는 규칙이 모든 클라이언트에게 적용되어야 한다면 도메인의 규칙이 될 것이고, 콘솔에서는 10자, 웹에서는 20자 같이 클라이언트에 따라 달라지는 규칙이라면 Presentation Layer에서 검증해야 하는 규칙이 된다.

 

다만, 각 도메인마다 모든 예외 메시지를 사용한다면 예외를 담는 객체가 너무 많아질 수도 있을 것 같아서 우선은 이름을 범용적으로 지었다. 이거는 이전 미션에서 다른 리뷰어님과도 얘기를 나눠본 적이 있었어서, 사실 꽤 고민이 되는 부분이었는데 우선은 ErrorCode를 제네릭하게 만들었고, 발생되는 이유가 별로 없기 때문에 이렇게 해도 한 예외가 하나의 도메인에서만 사용되고 있어서 괜찮다고 생각했다.

public class ResourceMinRangeException extends RuntimeException {

    private final ErrorData<Integer> range;

    public ResourceMinRangeException(final ErrorData<Integer> range) {
        this.range = range;
    }

    public ErrorData<Integer> getRange() {
        return range;
    }
}

예외 객체는 다음과 같이 만들었다. 자원이 최소 범위 미만의 값을 가졌을 때 발생하는 오류라는 의미로 담았다.

그리고, 해당 범위를 내부에서 인자로 관리할 수 있도록 (ErrorData<Integer>) 형태로 만들었다.

 

마지막으로 @ExceptionHandler를 통해 다음과 같이 예외를 처리하였다.

@ExceptionHandler(ResourceMinRangeException.class)
public ResponseEntity<ExceptionResponse> resourceRangeException(final ResourceMinRangeException e) {
    final Integer minRange = e.getRange().getData();
    final ExceptionResponse exceptionResponse =
            new ExceptionResponse(String.format("%d보다 큰 값을 입력해 주세요.", minRange));
    return ResponseEntity.badRequest().body(exceptionResponse);
}

내가 만약 동료 개발자와 협업을 하는 상황이고, 뷰에 내려질 예외 메시지에 대해 변경하고 싶다면 어떤 클래스를 확인할까? 라는 관점으로 고민해봤는데, 나라면 예외에 대해 핸들링하는 ControllerAdvice 부분을 먼저 확인할 것 같아서 위와 같이 진행하였다.

또한, 예외 response를 담는 객체를 따로 만들었었는데, 나중에 프론트 개발자와 협업했을 때 json의 값으로 바로 string이 내려오는 것보다, 공통된 포맷으로 데이터를 정해두고 내려주는 게 나을 것 같다고 판단했다. 지금은 메시지일 뿐이지만 나중에 상태 코드도 함께 내려온다든지... 그럴 수도 있기 때문에 객체로 감싸는 게 더 좋을 것 같다고 판단하기도 했다.

 

---

 💬 Dao와 Repository

나는 이번 미션을 진행하면서 다음과 같이 구성하였다.

위는 경주 결과에 대해 저장하는 테이블이고, 경주 횟수와 우승자, 그리고 경주 시작 시간을 담았다.

아래는 자동차에 대해 저장하는 테이블이고, 자동차 이름과 위치, 그리고 외래키로 경주 결과에 대한 아이디를 가졌다.

또한, 비즈니스 로직 상에서 하나의 경주에는 중복된 자동차 이름을 가질 수 없기 때문에 UNIQUE를 걸어주었다.

@Repository
@Transactional(readOnly = true)
public class CarRaceRepositoryImpl implements CarRaceRepository {

    private final CarDao carDao;
    private final RaceResultDao raceResultDao;
	...
}

그래서, 본 요구사항에서 정보를 저장할 때 하나의 Repository에서 저장하는 두 기능을 수행하기 위해 위와 같이 2개의 Dao를 참조하는 형식으로 진행했었다. 또한, 서비스 레이어에서 해당 레파지토리만 참조하도록 만들고 싶었다.

하지만, 다음과 같은 리뷰가 달렸었다.

두 Dao를 갖고 있는것이 단일책임원칙을 위배한다고 생각하지는 않으신가요?

나는 이에 대해서 다음과 같은 답변을 달았었다.

DAO의 경우 1:1 매핑이 되지만, Repository의 경우 Dao를 합쳐 조금 더 비즈니스 로직 관점에서 사용하는 계층이라고 생각했다.

만약 사용자의 트윗 목록을 가지고 오게 된다면, 사용자 정보를 담은 Dao와 트윗에 대한 Dao를 합쳐서 해당 Repository에서 이러한 기능을 수행한다고 생각했다. (당시 이 글을 보고 이러한 생각을 잡았었다.)

 

하지만, 리뷰어님은 나와 같은 상황에서 사용하는 게 아니라고 말씀해 주셨다.

당시 슬랙 허들을 통해 말을 나눴던지라 따로 기록은 못했는데, 내가 이해한 것은 다음과 같았다.

지금 나의 경우, 자동차와 경주 게임은 FK로 연결은 되어 있지만 나의 애플리케이션에서 하나의 도메인으로 연관이 되어 있지 않다.

오직 'Car'라는 도메인과, 'Race'라는 도메인만 존재할 뿐이지, 두 가지에 대해 집합된 도메인은 존재하지 않았다.

 

하지만, 위의 레퍼런스에서는 다음과 같이 레포지토리를 사용했었다.

public class UserRepositoryImpl implements UserRepository {
    private UserDaoImpl userDaoImpl;
    private TweetDaoImpl tweetDaoImpl;
    
    @Override
    public User get(Long id) {
        UserSocialMedia user = (UserSocialMedia) userDaoImpl.read(id);
        
        List<Tweet> tweets = tweetDaoImpl.fetchTweets(user.getEmail());
        user.setTweets(tweets);
        
        return user;
    }
}

여기서 주목할 부분은 userDaoImpl.read의 반환체가 UserSocialMedia라는 것이다.

Our UserSocialMedia class is a complex domain containing the properties of the User domain too.

사용자 도메인의 속성과 트윗에 대한 정보까지 담고 있는, 하나로 포괄한 도메인이라는 것이다.

그래서 DB의 정규화 관점에서 분리된 두 개의 테이블에 대해 하나의 도메인으로 집약하여 가져오고 싶을 때 사용한다고 생각했다.

 

🌱 DAO

- Data persistence의 추상화 (Database에 대한 추상화 계층)

- Database와 인접한 계층이며, 하위 수준의 개념이다.

- 데이터에 대한 매핑 및 접근할 수 있는 클래스

 

🌱 Repository

- 객체의 집합에 대한 추상화

- 도메인 오브젝트에 조금 더 가까운 개념이다.

- 도메인와 데이터 접근 계층 사이에 존재하는 레이어이다.

(물론, 도메인에 비즈니스 로직이 거의 없다면 Repository가 곧 단순한 Dao 형태가 될 수 있다.)

 

---

사실 그 외도 꽤나 느꼈던 점이 많은데, 이거는 회고로 쓰는 것보다 별도의 글로 쓰는 게 좋을 것 같아서 남겨둔다.

미션 종료 기간까지 최대한 블로그 글을 쓰는데에 집중해야겠다!