[DEVLOG] 우당탕탕 제발모발 v2 개발기 - 탈모 진단 API 수정하기 (2) 공통필드가 많은 DTO 만들기

 

🏝 0. 지난 글

[DEVLOG] 우당탕탕 제발모발 v2 개발기 - 탈모 진단 API 수정하기 (1) 변수 작명, Optional, Enum 활용

지난 글에서 Optional의 활용과 Enum의 활용예시를 볼 수 있습니다.

 

---

 

🤔 1. 지난 코드에서의 약간의 재수정

 

지난 코드 중, 진단 파트의 상태를 나타내는 Enum의 코드입니다.

@Getter
@AllArgsConstructor
public enum JBMBDiagnosisStateIdentifier {

    OPEN(1, "진단 시작", true),
    SURVEY(2, "설문조사 진행", true),
    UPLOAD(3, "이미지 업로드", true),
    DIAGNOSE(4, "진단 중", true),
    DONE(5, "진단 완료",false),
    ERROR(6, "에러 발생", false),
    SHUTDOWN(7, "진단 중단", false);

    private int stateCode;
    private String stateDescription;
    private boolean interruptible;
    
    public static boolean isShutDownAble(JBMBDiagnosisStateIdentifier diagnosisState){
    	return diagnosisState.isInterruptible;
    }

}

 

아래의 static으로 생성한 메서드의 필요성이 없다는 것을 깨달았습니다. 정적 팩토리 메서드로 새로운 인스턴스를 생성하는 것도 아니고, 이미 enum 객체에 interruptible이라는 필드가 있는데 다시 한 번 개발한 꼴이 되었습니다.

그래서, 해당 메서드를 삭제하고 interruptible의 이름을 shutDownAble로 변경했습니다.

 

@Getter
@AllArgsConstructor
public enum JBMBDiagnosisStateIdentifier {

    OPEN(1, "진단 시작", true),
    SURVEY(2, "설문조사 진행", true),
    UPLOAD(3, "이미지 업로드", true),
    DIAGNOSE(4, "진단 중", true),
    DONE(5, "진단 완료",false),
    ERROR(6, "에러 발생", false),
    SHUTDOWN(7, "진단 중단", false);

    private int stateCode;
    private String stateDescription;
    private boolean shutDownAble;

}

 

또, shutDownAble을 통해 필터링을 하는 로직도 일부 수정했습니다.

// 기존 코드
.filter(diagnosisInfo -> JBMBDiagnosisStateIdentifier
	.isShutDownAble(diagnosisInfo.getDiagnosisState()))

// 변경 코드
.filter(diagnosisInfo -> Optional.ofNullable(diagnosisInfo)
	.map(JBMBDiagnosisInfoEntity::getDiagnosisState)
	.map(JBMBDiagnosisStateIdentifier::isShutDownAble)
	.orElse(false))

 

기존에 생성했던 불필요한 메서드를 삭제하고, NPE 발생을 저지하기 위해 Optional을 사용한 구문으로 변경했습니다.

뒤에 상태 변경 후 save 하는 로직이 있기 때문에, Optional 내부가 비어있다면 false 처리를 해 save 되는 부분에 닿지 않도록 만들었습니다.

 

---

 

🤔 2. 응답에 공통필드가 많다! : DTO 정의

 

기존의 responseDTO들을 보면, 항상 내부 로직의 성공/실패 여부를 확인하기 위해 resultCode를 명시했습니다.

이러한 resultCode는 어떠한 응답이라도 모두 표기가 되어있었고, 해당 resultCode가 어떤 의미를 나타내는지, resultMessage도 공통적으로 필요했습니다.

 

그 외에도 error 여부, error 메시지, error가 발생한 원천, 응답 발생 시간 등등 다양한 요소를 공통필드로 묶어서 보내고 싶었습니다.

공통필드로 묶어서 보낼 수 있는 방법은, 제네릭 / 상속 / 구성 중 하나를 선택하는 방법입니다.

또 많은 DTO 클래스 파일이 생기는 것을 보완하기 위한 방법으로는 이너클래스를 사용하는 방법이 있습니다.

 

최종적으로 제가 선택한 방법은, 제네릭을 사용하면서 내부에 들어갈 DTO는 이너클래스 내부에 static으로 생성하는 방법을 선택했습니다.

- 공통필드가 숨겨진 상속과 구성보다는 강력하게 타입을 명시할 수 있고, 타입을 보는 것만으로도 관계를 확인할 수 있는 제네릭을 선택
- 응답마다 서로 다른 DTO를 생성하는 것은 필연적, DTO 클래스 파일이 프로젝트 폴더에 과하게 많아지는 것을 막기 위해 이너클래스를 사용.
- 공통필드와 같은 depth에 개별 DTO 필드를 확장하는 것이 아니라, responseBody까지 공통 필드고, 한 단계 더 깊은 depth에 개별DTO를 넣고 싶음.

+ 다른 방법으로 만드는 것에 대해서도 고려한 흔적은 다른 글에서 작성하도록 하겠습니다.

 

@Builder
@Getter
public class JBMBResponseObject<T>{

    /* Http Status */
    /* 삭제 필요, 이미 ResponseEntity에 있음. */
    private final Integer statusCode;

    /* 요청의 비즈니스 로직 처리 코드 */
    private final Integer resultCode;

    /* 요청 처리 코드의 메시지 */
    private final String resultMessage;

    /* 비즈니스 로직 처리 중, 에러 여부 */
    private final Boolean hasError;

    /* 에러 메시지, 없다면 None */
    private final String errorMessage;

    /* 에러 근원지, 없다면 None */
    private final String errorSource;

    /* 응답 시점 */
    private final String responseAt;

    /* 요청 시 접근한 API의 URL */
    private final String requestURL;

    /* 요청 결과 */
    private final T responseBody;

}

public class DiagnosisDTO {

    @Data
    @Builder
    @AllArgsConstructor
    public static class ResponseForInitDiagnosis {
        private Long diagnosisID;
    }
    
    ... 생략

    @Getter
    @Builder
    public static class RequestForInitDiagnosis {
        private String userID;
        private Boolean isThermal;
    }

    ... 생략
}

 

제네릭 타입으로 정의된 JBMBResponseObject<T>를 봅시다.

해당 부분에는 모두 공통적으로 가지는 필드에 대해 다 명시할 수 있습니다.

또 responseBody까지 공통으로 갖고, 그 내부에 들어가는 개별적인 값들만 한 단계 더 깊은 depth에 표현할 수 있으므로 제가 원하던 꼴과 동일합니다.

 

제네릭 타입에는 어떠한 Custom DTO도 다 들어갈 수 있기 때문에 앞으로 다른 도메인에서 다른 DTO를 만들더라도 여전히 재활용해서 사용할 수 있을 것입니다.

 

응답 별 DTO는 이너클래스로 만들었습니다. static 클래스로 만들어서 DiagnosisDTO 인스턴스를 생성하지 않아도 접근이 가능하도록 만들었습니다.

 

이너클래스로 만들었기 때문에 도메인 별로 묶을 수 있었습니다. 진단 초기화 응답, 설문 조사 응답, 이미지 제출 응답 등 프로젝트 폴더 내에 여러 파일이 생기는 것을 완화하고 내부에 넣어 관리할 수 있었습니다.

 

최종적으로 return 되는 타입의 예시를 보면,

public ResponseEntity<JBMBResponseObject<DiagnosisDTO.ResponseForInitDiagnosis>> forInitDiagnosis
    (final JBMBRequestObject<DiagnosisDTO.RequestForInitDiagnosis> requestForInitDiagnosis) {
    	... 생략
    }

 

ResponseEntity까지 더해지니 길이는 굉장히 길어졌지만, 어떤 타입을 리턴하는지 내부를 잘 보여줍니다.

1) ResponseEntity : status와 header와 body를 포함한 응답 객체
2) JBMBResponseObject : JBMB에서 만든 공통 응답 객체
3) DiagnosisDTO.ResponseForInitDiagnosis : 진단 DTO 중에서 진단 초기화에 관한 응답

 

 

아직 할 일이 더 남았습니다.

해당 DTO를 생성하고 나서, 응답을 생성할 때 빌더 패턴을 사용한 예시입니다.

 return ResponseEntity.ok()
	.contentType(MediaType.APPLICATION_JSON)
	.body(JBMBResponseObject.<T>builder()
		.statusCode(...)
		.resultCode(...)
		.resultMessage(...)
		.hasError(...)
		.errorMessage(...)
		.errorSource(...)
		.requestURL(...)
		.responseAt(...)
		.responseBody(...)
		.build()
);

이러한 응답을 생성하는 것은 모든 서비스의 메소드에서 적어도 하나씩 생성될 것입니다.

경우에 따라 다른 응답을 표현해야 하므로 특정 서비스의 한 메소드에서 여러번 등장할 수도 있습니다.

서비스의 응답마다 '성공'과 '실패'는 무조건 있습니다. 또 '유효하지 않은 요청'도 있죠.

 

이럴 때마다 매번 생성하는 것은 코드 길이가 길어질 수도 있고, 불편합니다.

따라서 재활용성이 높은 응답을 생성하는 responseCreator를 만들어보기로 했습니다.

 

다음 시간에는 Enum과 제네릭, 인터페이스와 정적 팩토리 메소드 등을 통해 responseCreator를 만들었던 내용을 적어보도록 하겠습니다.

 

[DEVLOG] 우당탕탕 제발모발 v2 개발기 - 탈모 진단 API 수정하기 (3) DTO에 따른 응답 생성 클래스 만