브랜드의 상품 목록 조회를 어찌 해야할까요?

[YeaChan05]

특정 브랜드의 상품목록을 조회하는 과정에서 몇가지 의문이 생겨 질문 올립니다

1. 어떤 도메인의 controller라고 봐야할까요?

이전에 민우님께도 한번 말씀 드렸지만 제가 개발할때는 어느 도메인의 정보를 응답하냐에 따라 구현할 도메인 패키지를 지정했었습니다
그래서 응답할 내용이 product인 경우에는 product패키지에 구현을, brand를 응답하는 경우에는 brand 패키지에 응답 내용을 구현했었습니다
문제는 현재 브랜드의 상품 목록을 조회하는데에 있습니다

브랜드의 경우 요청 path를 /brand/{brandId}이런식으로 지정하려고 했었습니다
그래서 당연히 구현을 brand에서 진행하려 했었구요

하지만 응답하게되는 객체는 SimpleProductDto를 페이징 응답하다 보니 product의 dto를 가져오게 되더라고요

그래서 요청과 응답 두가지가 하나의 도메인에 두려면 다소 어색한 상황이 나올거 같습니다

• brands/{brandId}로 요청하기 때문에 brand 패키지에 위치하지만 응답 객체는 product에서 가져옴
• product를 반환하기 때문에 product 패키지에서 응답하지만 requset path가 products?brandId=와 같은 형식이 됨
  그래서 어떤 방식이 현재 개발 방식인 DDD에 가까울지 고민입니다

2. Projection 객체를 응답에 그대로 사용하면 안될까요?

현재 상품 정보가 워낙 많다보니 상품 목록 조회에 경우에는 Projection을 사용하여 일부 데이터만 응답하도록 하는것이 쿼리 성능과 응답에 좋은 방향이라고 생각하여 SimpleProductDto를 사용하여 Projection한 객체를 받고 있는 서비스가 있습니다

마침 브랜드의 상품 목록을 조회하는 경우에도 상품의 일부 정보만 가져오면 되다보니 SimpleProductDto를 사용하면 좋을거 같더라고요

하지만 카테고리에서 상품 목록을 조회하는것과 브랜드의 상품 목록을 조회하는것은 응답이 약간 다르다는걸 확인했습니다
카테고리 상품 목록 조회와는 다르게 브랜드 상품 목록 조회에는 위시수와 브랜드 이름 조회가 없습니다

그래서 SimpleProductDto에 아래와같이 두개의 Projection 가능한 생성자를 제공하도록 @QueryProjection을 사용한 두개의 생성자를 만들었습니다

    @QueryProjection
    public SimpleProductDto(final Long productId, final String name,
                            final String photo, final BigDecimal price,
                            final String brandName, final Long wishCount) {
        this.productId = productId;
        this.name = name;
        this.photo = photo;
        this.price = price;
        this.brandName = brandName;
        this.wishCount = wishCount;
    }
    
    @QueryProjection
    public SimpleProductDto(final Long productId, final String name,
                            final String photo, final BigDecimal price) {
        this.productId = productId;
        this.name = name;
        this.photo = photo;
        this.price = price;
    }

문제는 지금 응답 객체로 SimpleProductDto을 담은 Page를 반환하고 있기 때문에 위시수와 브랜드 이름이 없는 생성자를 사용해 응답하는 경우�는 brandName와 wishCount가 null로 반환됩니다
구현 자체에는 문제가 안되겠지만 그닥 자연스러운 흐름이 아니라고 느껴지더라고요...

그래서 생각한 방법은 세가지가 있습니다

1. SimpleProductDto가 아닌 별도의 응답객체를 만들어 응답
2. Projection 용 DTO를 별도로 작성
3. @JsonIgnore을 사용하여 brandName와 wishCount가 null인경우 응답에서 제외하기

3번의 경우는 적용해보니 원하는대로 응답은 하지만 문제는 @JsonIgnore를 필드에 적용해야하다 보니 원치않게 brandName또는wishCount가 null이 된 경우에도 해당 필드가 응답 객체에 존재하지 않을 수 있다는 것입니다(프론트엔드 입장에서 개발하기 매우 난감할거 같아서요...)

세가지 방법중 어떤 방법이 최선일까요?
아니면 또다른 방법이 있을까요?

3번을 개선한 방법이 가능하다면 3번도 괜찮을거 같다는 생각이 드네요

위 두가지 상황에 대해 여러분의 의견이 궁금합니다

[kmw2378]

1.

개인적으로 두 번째 방법이 좋다고 생각해요. 그러나, 상품들은 하나의 브랜드에 속하므로 url을 brands/{brandId}/products 로 설계하는게 어떨까요?

추가로 Product와 Brand를 하나로 묶는 중간 엔티티를 설계하는건 어떨까요? 이러한 도메인을 추가하면 도메인간 의존성을 어느정도 해결할 수 있을 것 같아요!

public class Catalog {
    private final Brand brand;
    private final List<Product> products;
    ...
}

2.

응답이 다르다면 변경 포인트도 다르다는 뜻이므로 DTO를 나누는 방법을 어떨까요? 저는 분리의 기준은 변경 포인트라 생각하므로 응답이 비슷하더라도 나누는게 추후 유지보수에 유리할 것 같습니다.

[YeaChan05]

요청 path와 응답 dto 변경에대한 의견 감사합니다
의견 따라 path variable을 사용한 요청으로 구현해보겠습니다

각 도메인이 이미 종속적인(심지어 가장 핵심적인) 엔티티를 하나로 묶어 관리하는건 결국 도메인 의존을 해결하지 못한거라고 봐야하지 않을까요?
위와같은 방식을 사용하면 결과적으로는 도메인 객체를 사용해야 하니까요

도메인 의존을 부분적으로 허용을 하던지 아니면 다른 방법을 채택하면 좋을거같습니다