헥사고날 NestJs, TypeOrm dto type 리펙토링

간단한 설문조사 프로젝트를 만들던 중 문득 의문이 들었다.

 

의문

1. 인바운드 포트와 아웃 바운드 포트의 인풋, 아웃풋이 같은 경우가 상당히 많은데 구지 똑같은 타입을 여러개 선언할 필요가 있을까??
2. TypeOrm을 사용하기 때문에 엔티티의 클래스와 TypeScript의 유틸리티 타입을 사용하면 유지보수 측면에서 더 좋지 않을까?

리펙토링 도전

 

 before

 

survey/out-port/survey-findone.op.ts

인바운드 포트, 아웃바운드 포트의 output 타입은 같습니다.

export type SurveyFindOneOutPortOutputDto = {
  id: number;
  name: string;
  description: string;
  question: Array<{
    id: number;
    question_number: number;
    text: string;
    type: string;
    survey_id: number;
    created_at: Date;
    updated_at: Date;
    option: Array<{
      id: number;
      question_id: number;
      option_number: number;
      text: string;
      created_at: Date;
      updated_at: Date;
    }>;
  }>;
};

 

after

 

survey/types/index.ts

// 인바운드 포트, 아웃바운드 포트의 값이 같은 경우 이곳에서 관리
import { Survey } from '../survey.entity';

export type SurveyFindOneInPut = number;
export type SurveyFindOneOutPut = Omit<Survey, 'created_at' | 'updated_at'>;

survey/out-port/survey-findone.op.ts

import { SurveyFindOneInPut, SurveyFindOneOutPut } from '../types';

export type SurveyFindOneInPortInputDto = SurveyFindOneInPut;
export type SurveyFindOneInPortOutputDto = SurveyFindOneOutPut;
...

1. survey 모듈 내부에 types 디렉토리를 생성하고 인바운드 포트와 아웃바운드 포트의 인풋값, 아웃풋값이 같을 경우 types 파일 내 타입을 정의하고 인바운드 포트와 아웃바운드 포트는 types에 선언된 타입을 import하여 사용한다.
2. Survey 엔티티 타입과 타입스크립트 유틸리티 타입 Omit을 사용하여 공통 타입을 선언한다.

 

성과 : 

• 공통되는 타입을 한곳에서 관리하므로 유지보수가 더 쉬워졌다.
• 평소 헥사고날 아키텍처의 단점으로 '코드량이 많다'라고 생각했었는데 중복되는 코드를 줄일 수 있었다.