5. 공급자 클래스
process.env.ENV_KEY 는 기본적으로 다음과 같은 문제가 있습니다.
- 기본값이 undefined 입니다. → string 이 아니기에 여러 컴파일 에러를 유발합니다.
- 모든 값이 string 으로 파싱됩니다. → number 를 확정 지어주어야 합니다.
- jsonwebtoken 의 알고리즘 방식과 같이 지정된 값에 string 을 그대로 쓸 수 없습니다.
따라서 해당 KEY 가 호출 되는 시점에 필요한 값으로 변경 되어야 했습니다.
또한, 각기 다른 실행 환경, 개발, 배포, 테스트 에 따라서 다른 환경변수도 호출되어야 합니다.
따라서, EnvProvider 와 Env 의 협력을 통해서 이를 구현하였습니다.
서버에서 에러 상황 별로 다양한 Response 를 보내주면서도 간결한 코드를 유지해야 했습니다.
이를 위해, 값 전달 역할을 해줄 CustomException 을 만들고 이를 사용하였습니다.
또한, try-catch 의 불안정성을 해결하기 위해서 Error Handler 를 구현하였습니다.
위 두 가지를 사용하여 다음과 같은 이점을 얻었습니다.
-
전체적인 코드의 간소화
모든 에러는 각 공급자 함수 에서 처리 되었을 것으로 신뢰 합니다. 커스텀 예외가 아닌 경우는 예측하지 못한 에러 라고 판단하며 500 에러로 만듭니다. 모든 throw 는 Controller.prototype.method 에서 가공되어 반환에 사용됩니다.
-
서버의 안정성 확보
클라이언트의 사용 상의 에러로 인한 서버 다운이 어느 정도 예방 되었습니다.
-
높은 확장성
새로운 값의 반환이 필요하면 CustomException 을 수정하여 사용이 가능합니다.
서비스에서 다양한 값을 받게 되고 Joi 를 사용하게 되면서 코드의 길이가 너무 길어졌습니다.
이러한 부분이 비즈니스 로직의 가독성을 해치기 떄문에, 공급자 함수 와 DTO 의 협력으로 이를 해결하였습니다.
두 클래스는 Controller 계층에서 직접 호출되어 연결해놓았기 떄문에, Mocking 에 비효율적인 구조 임을 알게 되었습니다. 따라서, 두 협력자를 호출하기 위한 DtoFactory 를 구현하여 포장함으로써, 개선하였습니다.
DtoFactory 는 팩토리 패턴은 아니지만, 그 정체성이 모호하다고 판단했으며 내부적인 이야기 끝애 Factory 라는 단어를 붙이게 되었습니다.
