[Game_Crew_V2] 도메인 주도 설계

도메인 주도 설계 Domain - Driven Design 

트랜잭션 스크립트 패턴

이전에는 트랜잭션 스크립트 패턴으로 설계를 하였었다.

Service에 모든 비즈니스 로직이 있고 비즈니스 절차에 따라 도메인 객체를 이용해 처리하는 방식이었다.

 

도메인 객체는 단순하게 속성값만 이용되는 정보 묶음의 역할만을 하였다.

서비스에서는 대부분의 비즈니스 로직 처리가 이뤄지므로 중복되는 코드가 계속 생겨날 수 있고 이러한 점이 유지보수를 어렵게 하였다.

 

더하여 당시에는 테스트 케이스를 작성하지 않았는데(못함), 테스트의 복잡성을 높이고 관리하기 어려운 테스트 코드를 발생시킨다고 한다.

 

public class SignUpService {
	//...

    public void signup(SignupRequestDto requestDto){
		//...

        Optional<User> checkNickname = userRepository.findByNickname(nickname);
        if (checkNickname.isPresent()) {
            throw new CustomException(ErrorMessage.DUPLICATE_NICKNAME_EXISTS, HttpStatus.CONFLICT);
        }

        Optional<User> checkEmail = userRepository.findByEmail(email);
        if (checkEmail.isPresent()) {

            throw new CustomException(ErrorMessage.DUPLICATE_EMAIL_EXISTS, HttpStatus.CONFLICT);
        }
        
		//...
    }

    public void checkNickname(String nickname) {
        Optional<User> checkNickname = userRepository.findByNickname(nickname);
        if (checkNickname.isPresent()) {
            throw new CustomException(ErrorMessage.DUPLICATE_NICKNAME_EXISTS, HttpStatus.CONFLICT);
        }
    }

    public String checkAndSendEmail(String email) {
        Optional<User> checkEmail = userRepository.findByEmail(email);
        if (checkEmail.isPresent()) {
            throw new CustomException(ErrorMessage.DUPLICATE_EMAIL_EXISTS, HttpStatus.CONFLICT);
        }

        //...
    }

  	//...

 

[Game_Crew_V1]의 SignUpService이다. signup 메서드와 checkNickname 메서드, 그리고 checkAndSendEmail 메서드에서 각각 닉네임과 이메일의 중복 검사 로직이 중복되어 있음을 확인할 수 있다. 

도메인 주도 설계

[여기에 도메인 비즈니스 로직 코드]

• 도메인 객체가 속성뿐만 아니라 비즈니스 행위를 가지고 책임을 수행한다.
• 서비스의 메서드는 단순해진다. 거대한 서비스 클래스 대신 적절한 책임을 가진 여러 클래스로 구성되므로
  이해하기 쉽고 관리 및 테스트를 진행하기 쉬워진다.
• 코드의 양을 줄이고 재사용성도 높아진다.

도메인 주도 설계에 대해서는 더욱 배울 부분이 많지만 여기까지만 간단하게 알아보고 필요할 때에 점차 지식을 확장해 나가겠다.