[우테코 5기] 장바구니 미션 회고

헙크와 진행한 레벨 2 두 번째 페어 프로그래밍 미션인 장바구니 미션이다!

어쩌다 보니 레벨 1 데일리 조 팀원들과 한 번씩 페어 프로그래밍을 하는 느낌이다 ㅎ_ㅎ 재밌다!

 

이번 미션에서는 요구사항보다는 개인적으로 진행하고 싶은 부분들에 대해 구현하다 보니 되게 재밌게 구현했었다.

하지만... 지금 와서 코드를 보니 아직 많이 부족하다는 생각이 들었다 🥲... 어렵다!

 

---

✔️ 작성한 코드

GitHub - Cl8D/jwp-shopping-cart: 레벨 2 장바구니 미션 레파지토리

 

✔️ 1차 PR

[1단계 - 상품 관리 기능] 져니(이지원) 미션 제출합니다. by Cl8D · Pull Request #202 · woowacourse/jwp-shopp

 

✔️ 2차 PR

[2단계 - 장바구니 기능] 져니(이지원) 미션 제출합니다. by Cl8D · Pull Request #270 · woowacourse/jwp-shoppi

---

✔️ 기능 요구사항

- 상품 목록 페이지 연동하기 (Thymeleaf)

- 상품 관리 CRUD API 작성하기

- 관리자 도구 페이지 연동하기

- 상품 도메인 설계 (자유롭게, ID, 이름, 이미지 URL, 가격은 고정)

- 사용자 도메인 설계 (자유롭게, 이메일, 비밀번호는 고정)

- 사용자 설정 페이지 연동

- 장바구니 기능 구현 (상품 추가, 제거, 목록 조회, Basic 인증 방식)

 

나는 여기다가 사용자 추가, 상품 카테고리 기능, 관리자 기능, api 문서까지 적용해두었다.

rest-docs 관련해서는 추가적으로 글을 작성할 예정이다 ㅎ_ㅎ

---

늘 그랬듯이 고민했던 부분과 나름의 솔루션에 대해서 작성해보고자 한다.

 

 

💬 Redirect가 무엇일까?

사실 이거는... 내가 리다이렉트에 대한 개념을 제대로 잡지 못해서 발생한 문제였다 🥲

@GetMapping
public String getProducts(final Model model) {
    final List<ProductDto> products = productService.getProducts();
    model.addAttribute("products", products);
    return "admin";
}

위와 같은 코드에서 뷰 이름을 반환하는 것은 리다이렉트로 봐야 하냐고 질문을 드렸었다.

리다이렉트는 요청한 리소스가 다른 위치에 있으니, 해당 리소스 위치를 반환할 때 사용하는 것이다.

-> 해당 리소스의 주소로 다시 요청을 날리는 것과 동일하다.

위와 같이 뷰 이름을 반환하는 것은 단순히 요청에 대한 렌더링을 해주는 것이기 때문에 리다이렉트로 보기는 어렵다.

 

이거는 추가적으로 JS 쪽 코드인데... 관련은 없지만 새롭게 안 거여서 정리해둔다.

	location.href	location.replace
기능	새로운 페이지로 이동	기존 페이지를 새로운 페이지로 변경
형태	속성	메서드
주소 히스토리	기록된다 (뒤로 가기 가능)	기록되지 않는다
예시	location.href=""	location.replace("")

 

---

 

💬 유효성 검사는 어디에서 해야 하는가? - 도메인 vs DTO

public class ProductDto {

    @Length(min = 1, max = 25, message = "상품 이름의 길이는 {min} ~ {max}글자여야 합니다.")
    private final String name;

    private final String imageUrl;

    @NotNull(message = "상품 가격은 비어있을 수 없습니다.")
    @Range(min = 0, max = 10_000_000, message = "상품 가격은 {min} ~ {max}원까지 가능합니다.")
    private final Integer price;

    @NotNull(message = "상품 카테고리는 비어있을 수 없습니다.")
    private final ProductCategory category;
}

처음 코드를 작성했을 때는 위와 같이 DTO에서 이름, 가격에 대한 세부 조건들도 제어할 수 있도록 validation 어노테이션을 활용하였었다.

🌱
저는 개인적으로 유효성 검사도 여러가지 종류가 있다고 생각하는데요.
1. 비즈니스와 관련된 유효성 검사
2. 단순 유효성 검사
요렇게 나누어서 처리할 수 있는 레이어가 있다고 생각해요!

하지만 리뷰어님은 다음과 같이 유효성 검사를 하는 부분을 나눠보는 게 어떠냐고 이야기를 해주셨다.

당시에는 validation annotation에 굉장히 집착(?)을 하고 있었어서, 도메인에서 @Range, @Length 같은 어노테이션을 활용하여 검증하면 도메인에서 뷰에 출력할 문구를 의존하는 형태가 될 것 같아서 선뜻 그렇게 하기가 어려웠다. (지난번 미션 때 이 부분에 대해서 피드백을 들었어서 더 조심스러웠던 것도 있다 ㅎㅎ)

 

하지만...! 생각해보면 굳이 validation annotation을 사용할 필요는 없었다.

레벨 1 미션에서는 그냥 자바 코드로도 충분히 검증을 했었고, 만약 새로운 개발자가 와서 '상품 도메인에 필요한 필드들의 제약 사항은 어디에서 관리되지?'라고 생각했을 때 DTO보다는 도메인 클래스를 먼저 열어볼 것 같았다.

 

또한, 지금은 SSR이기 때문에 메시지 자체가 바로 뷰로 노출되지만, CSR 상황이라면 여기서 전파되는 메시지는 실사용자가 아닌 상대 개발자, 즉 클라이언트가 확인하는 메시지이기 때문에 '도메인이 뷰에 출력될 메시지를 관리한다'라는 관점과는 조금 떨어져 있다고 봐도 된다.

 

무엇보다 도메인 객체는 POJO로 관리되는 게 더 좋을 것 같아서, 아래와 같이 그냥 자바 코드를 통해 검증을 진행해주었다.

public class ProductName {

    private static final int NAME_MIN_LENGTH = 1, NAME_MAX_LENGTH = 25;

    private final String name;
	
    ...

    private static void validateNameLength(final String name) {
        if (name.length() < NAME_MIN_LENGTH || name.length() > NAME_MAX_LENGTH) {
            throw new GlobalException(PRODUCT_NAME_LENGTH);
        }
    }
}

그리고 DTO 쪽에는 단순히 유효성 검사를 진행해주었다.

public class ProductRequest {

    @NotBlank(message = "상품 이름은 비어있을 수 없습니다.")
    private final String name;

    @NotNull(message = "상품 가격은 비어있을 수 없습니다.")
    private final Integer price;

    @NotNull(message = "상품 카테고리는 비어있을 수 없습니다.")
    private final String category;
    ...
}

 

앞으로는 다음과 같은 기준을 통해서 유효성 검증을 해보고자 한다.

- DTO : 데이터 타입에 대한 검증
ex.
숫자값이 올바르게 들어오는가?
빈 값이 들어오는가?
전화번호 형태 (-로 구분된 13글자)인가?
이메일 형태 (@로 구분된 형태)인가?

- 도메인: 비즈니스 요구사항에 대한 검증
ex.
가격은 0원 ~ 10000원 이하의 값을 가지는가?
이름의 길이는 최소 1글자 이상인가?
이메일의 도메인이 특정 도메인만 사용하는가? (gmail, daum, naver... etc)

 

---

 

💬 Dto <-> Entity 변환 로직은 어디에 있으면 좋을까?

public class ProductDto {
    public Product toEntity() {
        return new Product(name, imageUrl, price, category);
    }

    public static ProductDto fromEntity(final Product product) {
        return new ProductDto(product.getId(), product.getName(), product.getImageUrl(),
                product.getPrice(), product.getCategory());
    }
}

사실 이거는 정말 리뷰어님마다 정말 많이 갈리는 부분인 것 같다.

 

내 리뷰어님 같은 경우는 의존관계가 Controller -> Dto -> Entity와 같은 형태로 흐르게 된다면 컨트롤러에서 해당 Dto 클래스를 통해서 도메인에 대해 접근할 수 있는 여지가 생기는 게 아니냐고 말씀해 주셨다.

물론, 개발자의 이해도가 높다면 Dto에서 Entity로 변환하여 컨트롤러에서 코어한 도메인 계층의 객체를 침범하는 경우는 거의 없겠지만, 클린 아키텍처의 시작은 '~한 위험이 있지 않을까?'로 부터 시작된다고 생각하기 때문에 이런 위험성은 끊어주는 게 옳다고 생각했다.

 

그래서 리팩터링 시에는 service layer에서 private method를 통해 위와 같은 변환 로직을 처리하도록 만들었고, 추후 매핑하는 클래스들이 많아진다면 별도의 mapper class를 두어서 처리하는 것으로 생각하였다. (매퍼 클래스 역시 service와 같은 곳에 위치)

 

+) 의존 관계를 단방향으로 가져가려면 dto가 존재해야 하는 패키지는 service 쪽이어야 한다 😊

아무 생각 없이 controller 쪽에 두었다가 controller -> service -> dto 같은 요상한 흐름 관계가 생겨버렸었다... ㅎ_ㅎ 유의하자!

 

---

 

💬 엔티티와 도메인

아마 이번 미션에서 나를 가장 많이 괴롭혔던 주제인 것 같다 🥲 (여전히 결론을 확실하게 내리지 못한 상태이다)

사실 처음 페어 프로그래밍을 할 때는 엔티티와 도메인을 구분하지 않고, 그냥 엔티티 자체를 도메인이라 생각하고 코드를 작성했었다.

 

미션 요구사항이 CRUD이다 보니까 DB와 굉장히 밀접해지고, 테이블에 내용을 삽입하거나, 조회하거나 하는 로직만 있다 보니 별도의 비즈니스 로직이 없다고 생각되어 별도로 둘 필요성을 느끼지 못했기 때문이다. 또한, 엔티티의 경우 DB와 1:1로 값을 매핑하고, 별도의 로직 없이 단순히 값을 반환하는 역할만 해야 한다고 생각했었다. 

 

하지만, 위에서 비즈니스 요구사항에 대한 검증을 진행하기 위해서는 도메인 클래스가 필요했다.

엔티티에서 검증을 진행하기에는, 엔티티가 비즈니스 로직을 가지는 것 같아서 하고 싶지 않았고, 그렇다고 도메인을 만들기에는 단순히 검증밖에 안 하기 때문에 굳이 만들어야 하나...? 라는 생각도 들었기 때문이다... 🥹 (여기서 머리 터짐)

 

하지만, 리뷰어님이 다음과 같은 피드백을 남겨 주셨다.

🌱 저는 도메인은 항상 있어야 한다고 생각해요.
새로운 개발자가 도메인에 대한 요구사항을 확인하기 위해서는 어떤 클래스를 확인할까요?

이 말을 듣고 나름대로 도메인과 엔티티에 대한 정의를 내려 아래와 같이 답변을 했다.

말이 길지만 요약하자면, 비즈니스 로직을 표현하기 위한 객체는 도메인 객체며, 영속성 레이어와 강결합을 맺은, 도메인 객체를 표현하기 위한 데이터들을 저장하는 객체는 엔티티라고 생각했다. 그래서 도메인 / 엔티티를 따로 분리해서 코드를 작성했었다.

 

하지만, 이러한 정의에서도 결국 문제가 발생할 수밖에 없었다.

바로... Join을 통해서 조회해올 때는 어떻게 엔티티로 처리해야 하는지 결정할 수 없는 것이었다.

기존에는 조인을 진행하는 주 테이블에 대한 dao (CartDao)에서 아래와 같이 코드를 작성하였고, MemberProductEntity라는 객체를 생성하여 조회해온 결과를 담아오도록 만들었다.

public class MemberProductEntity {
    private final Long cartId;
    private final Long memberId;
    private final Long productId;
    private final String productName;
    private final String productImageUrl;
    private final int productPrice;
    private final String productCategory;
	
    ...
}

public List<MemberProductEntity> getProductByMemberId(final Long memberId) {
    final String query = "SELECT c.id, c.member_id, c.product_id, p.name, p.image_url, p.price, p.category " +
            "FROM cart c JOIN product p ON c.product_id = p.id WHERE c.member_id = ?";
    return jdbcTemplate.query(query, (result, count) ->
            new MemberProductEntity(result.getLong("id"), result.getLong("member_id"),
                    result.getLong("product_id"), result.getString("name"),
                    result.getString("image_url"), result.getInt("price"),
                    result.getString("category")), memberId);
}

-> 1줄 요약: SRP 위반 아닐까요? + 엔티티를 이런 식으로 써도 되나요? + 결국 도메인과 엔티티의 차이점이 뭐죠? (다시 원점)

당시에는 엔티티는 도메인으로서 역할을 할 수 있지만, 정보 전달에 가까운 객체라면 가능하다고 생각해서 저런 구조로 했다.

 

갓 리뷰어님은 이걸 보고 아래와 같이 피드백을 남겨주셨다.

🌱 도메인: 우리가 해결하고자 하는 문제 영역이자, 문제 영역을 클래스화 하여 코드로 옮긴 부분
🌱 엔티티: 식별자를 가지고 있는 객체
위 정의대로라면 도메인이 더 큰 범위이면서, 엔티티가 그 일부분으로 보일 텐데, 맞습니다!

도메인에는 VO, Entity, Domain Service 등 많은 것들이 포함되어 있으며, 문제 영역을 클래스화 한 것이라면 모두 도메인으로 바라본다고 하셨다. (이에 대해서 오늘 허브랑도 이야기를 나눴었는데, 허브의 리뷰어님도 비즈니스 로직에 대한 Service Layer를 도메인 쪽으로 바라본다고 말씀해 주셨다.) 그리고, 그 중에서 식별자가 있다면 엔티티가 된다.

 

여기서 식별자는 비즈니스 상으로 두 개의 객체를 분리할 수 있는 고유한 기준이다.

DB의 pk 값이라고 생각할 수 있겠지만, PK가 될 수도 있고 다른 필드 값이 될 수도 있다.

어떠한 객체를 구분하는 기준이기 때문에, 만약 비즈니스 로직 상 '이름'이라는 필드가 고유하게 존재한다면 해당 객체는 '이름'이라는 식별자를 가진 엔티티가 될 수도 있는 것이다. 별도의 식별자가 있는 도메인은 곧 엔티티라고 말할 수 있으며, 이 단계에서는 DB에 대한 정보를 고려하지 않게 된다.

 

마틴 파울러는 다음과 같이 각 개념들을 정의하였다.

- Entity: Objects that have a distinct identity that runs through time and different representations. You also hear these called "reference objects".

- Value Object: Objects that matter only as the combination of their attributes. Two value objects with the same values for all their attributes are considered equal. I also describe value objects in P of EAA.

- Service: A standalone operation within the context of your domain. A Service Object collects one or more services into an object. Typically you will have only one instance of each service object type within your execution context.

이전 미션을 하면서 Reference Object와 Value Object에 대해서 공부한 적이 있었는데 여기서 엔티티를 Reference Object로서 생각한다는 점을 보고 확실하게 이해하게 되었다. 식별자로 상태가 변하는 객체가 되는 것. 우선 나는 이 정도로 이해를 했다. 그래서 보통 엔티티는 식별자로 동일성을 정의할 수 있기 때문에 equals, hashcode를 일반적으로 정의하지 않는다. 

 

아무튼, 다시 돌아와서... 엔티티를 데이터베이스 테이블에 해당하는 객체로 자주 사용하는 이유는 보통 PK를 이용해 식별이 되는 Reference Object이기 때문이다. 그래서 이번 레벨에서는 DB의 PK를 식별자로 사용하는 엔티티를 별도로 두었다.

 

그리고, 장바구니에 대한 CUD 로직은 다음과 같이 풀어나갔다.

- '장바구니 (Cart)' 라는 도메인은 Member와 List<Product>의 조합으로 만들기.
: 한 명의 사용자가 담은 물건 리스트를 관리하는 도메인 객체.

- 장바구니 상품 저장, 제거 시 식별자를 가진 엔티티인 CartEntity를 활용하면 바로 insert가 가능하기 때문에 (본 비즈니스 로직은 DB에 대한 연산이 위주임) 별도의 도메인 객체로 표현할 필요가 없을 것 같다고 판단. (어차피 엔티티도 문제를 해결하는 범위로 본다면 도메인 객체에 들어갈 수 있다.)

- 장바구니 상품 정보 반환 시 조인을 사용하다 보니 Entity보다는 DTO로 사용 (여러 값들을 조합해서 사용하고 있음)

말이 길지만 결과적으로 엔티티와 도메인을 분리했다.

 

대충 한 가지 예시 코드를 보여주자면 이런 식이었다.

public CartResponse getCartResponseByMemberEmail(final String memberEmail) {
    final MemberEntity memberEntity = getMemberEntity(memberEmail);
    final List<CartDto> cartDtos = cartDao.getProductsByMemberId(memberEntity.getId());
    final Cart cart = convertToCart(memberEntity, cartDtos);
    final List<ProductResponse> productResponses = convertToProductResponse(cart);
    final int productCount = cart.getProductCount();
    return new CartResponse(productCount, productResponses);
}

다만, 이 과정에서 entity -> domain으로 만드는 컨버팅 로직이 많아져서 코드가 약간 보기 힘들어졌다.

또한, 서비스 레이어에서 도메인, 엔티티를 둘 다 가지고 있으면서 service -> entity(persistence layer), service -> domain와 같은 순환참조 형태가 발생해서 단방향으로 데이터가 흐르지 않게 되었다.

이를 해결하기 위해서 다음 미션에서는 다른 방법을 적용했는데...! 이거는 지하철 미션 끝나고 포스팅 해보고자 한다.

 

다음 미션도 파이팅! 💪