2023_6_20_TIL

上男子 되는 길

上男子 TIL

도메인 주도 설계에 대해서 배웠다. 정확하게는 배웠다기 보다는 코드 리펙토링을 멘토님과 함께 하다보니까. 현재 우리가 작성한 코드의 문제점을 지적해주셨다.

@Transactional
    public UserResponse.SignupOutDTO signupService(UserRequest.SignupInDTO signupInDTO) {
        existsUserByEmail(signupInDTO.getEmail());

        String encPassword = passwordEncoder.encode(signupInDTO.getPassword()); // 60Byte
        signupInDTO.setPassword(encPassword);
        System.out.println("encPassword : " + encPassword);

        // 디비 save 되는 쪽만 try catch로 처리하자.
        try {
            User userPS = userRepository.save(signupInDTO.toEntity());
            userPS.generateEmailCheckToken();
            SimpleMailMessage mailMessage = new SimpleMailMessage();
            mailMessage.setTo(userPS.getEmail());
            mailMessage.setSubject("3D 에셋 스토어, 회원 가입 인증");
            mailMessage.setText("/check-email-token?token=" + userPS.getEmailCheckToken() + "&email=" + userPS.getEmail());
            javaMailSender.send(mailMessage);

            return new UserResponse.SignupOutDTO(userPS);
        } catch (Exception e) {
            throw new Exception500("회원가입 실패 : " + e.getMessage());
        }
    }

/**
     * 공통 메소드
     */
    // 요청한 사용자가 id의 주인인지 확인하는 공통 메소드
    public User findUserById(Long userId) {
        User userPS = userRepository.findById(userId).orElseThrow(
                () -> new Exception400("id", "존재하지 않는 유저입니다. ")
        );
        System.out.println("출력됨: " + userPS.getEmail());
        return userPS;
    }

    // 요청한 사용자가 email의 주인인지 확인하는 공통 메소드
    public User findUserByEmail(String email) {
        User userPS = userRepository.findByEmail(email).orElseThrow(
                () -> new Exception400("email", "존재하지 않는 유저입니다. ")
        );
        return userPS;
    }

    // 요청한 사용자 email이 존재하는지 확인하는 공통 메소드
    public void existsUserByEmail(String email) {
        boolean userCheck = userRepository.existsByEmail(email);
        if(userCheck){
            throw new Exception400("email","이미 존재하는 이메일입니다. ");
        }
    }

    // 요청한 사용자가 권한이 있는지 확인하는 공통 메소드
    public void authCheck(MyUserDetails myUserDetails, Long userId){
        if (!myUserDetails.getUser().getId().equals(userId)) {
            throw new Exception403("권한이 없습니다. ");
        }
    }

보면 나름 공통화를 한다고 우리는 같은 과정을 하는 로직을 따로 빼서 메소드를 만들고, 간단화 하는 작업을 했다.

하지만 단점으로는
1. 해당 메소드(user 권한을 체크하는 과정)를 사용하는 다른 서비스에서도 무조건 적으로 의존을 하게 된다.
2. 해당 단위 테스트를 할때, 너무 힘들다. 왜냐하면 각각에 대해서 가정법 처리를 해줘야하기 때문이다.

따라서 해결 방법으로는
1. 단위 테스트는 최대한 의존하는 것 없이(예를 들면, stub 또는 다른 부가적인 기능) 돌아갈 정도로 하는 것을 목표로. 즉, 테스트하고자 하는 코드의 내부에 변경사항이 있는 메소드는 전부 도메인에 넣자. -> 도메인 주도 설계
2. AOP를 사용하거나 Interceptor를 사용해서 처리를 하자. 왜냐하면 1가지의 메소드가 의존성을 받다보면 느슨한 결합이 되지 않는다.

하지만 현재 우리 팀원의 개발속도, 상태, 마감일 이 3가지를 고려했을 때는 리펙토링은 현 시점에서 불가능하다고 생각을 했다.

그래서 일단 기능 구현과 통합 테스트까지만 구현을 하는 것으로 목표를 잡았다.

솔직히 까먹을 것 같아서 기록한 거지유 ㅎㅅㅎ

上男子

上男子 스케줄

上男子 스케줄

상남자 스케줄

上男子 노션

상남자의 공부 노션