[이호석] DAY7 상점 도메인 추가 및 swagger 설정(완료)

[HiiWee]

To Reviewer

안녕하세요 모그님!
기존 도메인과 연관관계를 갖는 새로운 도메인이 추가되면서 발생된 변경사항들과 문제들을 해결해보는 경험을 할 수 있었습니다!
미션을 진행하면서 새롭게 고민됐던 부분들이 몇 개 있었습니다!
(5, 6, 7미션에 대한 pr이 열려있어서 변경점이 전부 통합되어 보입니다! chore: swagger 설정 추가5ec343c 부터 7회차 미션 커밋입니다!

✅ 특정 도메인의 서비스에서 다른 도메인의 Service or Repository 이용?

Product는 Store와 N : 1의 연관관계를 가지고 있고, 임의로 추가한 요구사항은 다음과 같습니다.

• 상품은 반드시 상점에 속해 있어야 한다.

위 요구사항을 만족하기 위해 ProductService에서 StoreService 혹은 StoreRepository에 접근했어야 했습니다.
이 때 Store를 찾기 위해서 서비스, 레포지토리 중에서 어떤것을 사용하는것이 적절할지 고민이 됩니다!

    // ProductService에서 StoreService를 이용하면 예외에 대한 처리를 StoreService에게 맡길 수 있다.
    // 하지만 dto -> domain 변환 작업을 해주어야 하는 번거로움이 존재
    StoreResponse storeResponse = storeService.findById(productRequest.getStoreId());
    
    // ProductService에서 StoreRepository를 이용하면 예외에 대한 처리를 직접 해주어야 한다.
    // dto -> domain 변환 작업이 필요 없지만, store 패키지에 존재하는 예외를 product 패키지가 의존하게 된다.
    // 이것이 강한 의존성을 만드는것 아닌가? 싶었지만, 이미 StoreService를 쓰고있는 입장에서 의미가 있을까 하는 고민!
    StoreResponse storeResponse = storeRepository.findById(productRequest.getStoreId()).orElseThrow(예외던짐);

✅ dto에서 toDomain이 적절할까?

정적 팩토리 메소드를 통해 dto객체의 인자로 도메인을 받아 dto로 변환한 객체를 반환하는 패턴은 많이 사용됩니다!
그렇다면 그 반대인 dto -> domain을 만들어주는 toDomain도 사용해도 괜찮지 않을까? 하여 사용해왔습니다.
저는 너무 당연하게 사용하고 있었는데, 코드를 작성하면서 과연 정말 옳게 사용하고 있는건지 의심이 되어 질문드립니다!

블로그 링크

[스터디] 상점 도메인 추가 및 Swagger 설정(7회차)

[mog-hi]

✅ 특정 도메인의 서비스에서 다른 도메인의 Service or Repository 이용?
이 부분은 여러 의견이 있습니다. woowacourse/retrospective#15 여기 참고해보세요!
현업에서는 다른 도메인에 접근해야할 때는 주로 Service에서 Service를 의존하긴 합니다~!

✅ dto에서 toDomain이 적절할까?
(domain이 entity를 의미한다고 이해하고 답변했습니다!)
위치는 괜찮을 것 같습니다. 실제로 많이들 dto 내에 to~~로 변환해주는 메소드를 구현하고요.
그런데 정적 팩토리로 구현하신 이유가 있나요??! (맞고 틀리다가 아니라 이유가 궁금해서요!! ㅎㅎ)

[HiiWee]

안녕하세요 모그님!!
질문주신것에 대해 제 생각을 간략히 적어봤습니다!

✅ 정적 팩토리 메소드로 구현한 이유

toDomain()을 정적 팩토리 메소드로 구성하지는 않았습니다!

repository를 통해 조회한 Entity 클래스를 알맞은 dto로 변환할때 매개 인자로 Entity를 받아와서 dto로 변환하는 로직을 정적팩토리 메소드로 두었습니다!

제가 정적 팩토리 메소드를 사용한 이유는 다음과 같았습니다!

1. 실제 데이터를 다루며 객체를 생성하는 부분을 dto 클래스로 캡슐화하여 서비스 코드가 간결해집니다.
2. 단순 new Dto()가 아니라 변환하는 로직에 목적에 맞는 이름을 부여할 수 있다.

1번의 경우 필드가 많은 Entity의 경우 dto 내부로 캡슐화 하게 되면 서비스 코드를 간결화 시킬 수 있었습니다!
2번의 경우 생성 목적에 따른 알맞은 이름을 부여할 수 있다는 장점이 있었습니다.

추가로 링크 주실 글 잘 읽어봤습니다! 제가 생각하지 못했던 부분에 대해 고민할 수 있는 계기가 됐습니다! 감사합니다!!

[mog-hi]

@HiiWee 그렇군요! 설명 감사합니다!!
이펙티브 자바를 실천하고 계시군요! ㅎㅎㅎ
저는 toDto나 toDomain의 위치나 구현방법이 다 근거가 충분하고, 합리적이라고 생각합니다👍