refactor: 빈약한 도메인 모델 개선 및 의존성 변경

[mete0rfish]

🔥 구현 기능

빈약한 도메인 모델 개선 및 의존성 변경

🚧 작업목록

• 빈약한 도메인 모델 개선
• 의존성 변경

⏰ 추정 시간

4시간

🔗 관련 링크

[mete0rfish]

역방향 레이어드 아키텍처 구조 개선

현재 프로젝트는 아래와 같은 레이어드 아키텍처를 사용중이다.

레이어드 아키텍처의 조건 중 가장 중요한 요소인 단방향 의존성만을 가져야 한다라는 조건을 현재 어기고 있다. Presentation 레이어에 포함된 MemberFindEmailRequest를 Business 레이어에서 의존하는 코드를 사용중이기 때문이다.
만약 이메일을 찾기위해 추가적인 요소로 직무 필요하다고 해보자. 그러나 정작 비즈니스 로직 단에선 기존 두 가지 요소(이름, 폰 번호)만으로 유저 식별이 가능하기 대문에 모든 요소가 필요하지 않다.

따라서, DTO 재사용 시 코드 변경에 영향을 받을 수 있다. 따라서, 목적에 맞게 DTO를 분리하려고 한다.

// MemberEmailController
@PostMapping("/find-email")
public ApiResponse<?> findEmail(@RequestBody MemberFindEmailRequest request) {
    String email = memberBusiness.findEmail(request);
    return ApiResponse.onSuccess(email);
}

// MemberBusiness
@Transactional(readOnly = true)
public String findEmail(MemberFindEmailRequest request) {
    Member member = memberService.findOne(request.name(), request.phone_num());
    return member.getEmail();
}

따라서, MemberFindEmailRequest라는 DTO를 직접 파라미터로 넘기지 않고, MemberFindEmailCommand라는 별도의 DTO를 만들어 이를 해결하려고 한다.

[mete0rfish]

현재 MemberRepository는 JpaRepository를 상속받은 JPA용 레포지터리 입니다. 해당 구조는 JPA라는 기술에 종속되는 문제점을 가지고 있습니다. 만약 MongoDB나 다른 다큐먼트 데이터베이스로 마이그레이션 시, 서비스의 코드 수정이 불가피합니다. 따라서, Repository 인터페이스를 별도로 만들어 DIP를 통해 이를 해결해보려고 합니다.

문제 해결 후 그림은 아래와 같습니다.

[mete0rfish]

비즈니스 객체 사용에 대해

단점

1. 비즈니스 객체는 단순히 프록시 역할만 수행하기 때문에 책임을 가지지 않는다.
2. 비즈니스 레이어가 비즈니스 객체와 서비스 객체로 분리되어 있어 흐름 추적이 어렵다.
3. 1번의 이유로 인한 테스트 코드 무의미

    @Test
    void 도면을_생성한다() {
        // given
        BlueprintRequest request = BlueprintFixture.createBlueprintRequest();
        Blueprint blueprint = Blueprint.fromRequest(request);

        when(blueprintService.saveBlueprint(any(Blueprint.class)))
                .thenReturn(blueprint);

        // when
        Blueprint savedBlueprint = blueprintBusiness.createBlueprint(request);

        // then
        assertThat(savedBlueprint.getBlueprintName()).isEqualTo("대한민국 마을");
    }

Request와 Blueprint를 미리 지정해놔서 Stub하고 createBlueprint를 실행하는 것이 끝이다. 비즈니스 객체가 현재 단순히 프록시 객체로 사용되기 때문이다. 이런 테스트 코드를 작성하는 의미가 없다고 생각한다. 테스트 코드는 설계자의 흐름을 나타내기 위한 수단으로 사용된다. 그러나 비즈니스 객체는 너무나도 단순한 기능 (역할이라고 부를 수 도 없는)만 수행하기 때문에 테스트 코드를 작성하는 의미가 없다. 쉽게 말해 프로덕션 코드만 보더라도 충분히 다른 개발자들이 이해할 수 있는 수준의 코드라고 생각한다.