메일 발송을 위한 sendModule에 대한 좀더 자세한 이야기를 작성해보려고 한다.
현재 Node.JS 런타임 환경에서 service 레이어에서 프레임워크(외부 API)의 기능을 필요로 할때, 이에 대한 상세를 service 레이어에서 알고 있지 않게끔 설계하는게 가장 큰 목적이였다.
비즈니직 로직과 프레임워크 워크의 구현체가 서로 최대한 느슨한 연결관계를 가지를 수 있도록 해야한다.
일반적으로 interface를 작성하여 이에 의존시키는 방법이 일반적이지만 Javascript 환경에서는 이런 구현에 제한이 있다.
(typeScript를 생각할 수 있지만 이를 사용하지 않는 상황이다)
이를 해결하기 위해 중간관리자 역할을 수행 할수 있는 모듈을 제작하게 되었고 이게 sendModule이다.
(이런 유사한 방식으로 Publisher/Subscriber(Pub-Sub) 패턴이 있다고 한다)
아키텍처 레이어
먼저 의존성 관리를 위해 최종적으로 레이어를 다음과 같이 관리할 예정이다.
- domain (dto)
- service (unitModule)
- controller
- framework (kakao,email,push ...)
이에 대해 모든 의존성으로 아래에서 위 방향으로 향해야 한다.
이때 service 레이어에서의 framework의 기능 호출로 인한 의존성 역전이 발생하고 이를 해결하기 위한 방법이다.
관심사 분리
전송을 위한 행위를 완료 하기 위해서 필요한 요소를 관심사에 맞게 분리하고 의존성을 관리해 주기로 했다.
- 도메인 dto (전송을 위한 데이터 폼을 작성하고 모든 의존성의 중심)
- 비지니스 로직 template (전송에 대한 정형화된 파라미터의 상세)
- 실행을 위한 프레임워크 로직 sendApi (전송을 위한 로직)
현재 작성되어 있는 sendApi에 대한 작성 로직을 다음과 같이 3가지로 분리하여 sendModule에서 service 레이어와 framework 간의 의존성을 끊어내기 위한 수단으로 사용했다.
구현
dto 객체
dto의 경우 Javascript에서 정의하기 가장 난감한 부분이라고 생각된다.
해당 dto는 어떠한 비지니스 요청을 온전히 처리하기 위한 요소들을 정의한다.
template 함수
unitModule에서 전송에 관련된 요청이 필요할 때 해당 함수를 사용하여 전송을 위한 dto 객체를 만들게 된다.
해당 함수의 요구 파라미터는 각 함수마다 고유하지만 해당 함수들은 반드시 dto로 정의된 객체를 반환한다.
sendApi 함수
전송을 위한 패키지 및 함수에 대한 로직이 작성되며 해당 함수의 요구 파라미터는 dto의 객체중 하나가 된다.
의존방향 정의
다음 그림처럼 sendModule은 중간에서 요청에 대한 message를 입력받고 입력받은 message의 타입과 일치하는 요구 파라미터를 가지는 함수에게 전달하게 된다.
비지니스 로직을 구현하는 유닛모듈에서는 자신이 원하는 요청에 대한 dto 객체를 template 함수를 통해 생성하고 이를 sendModule에 등록하기만 하면된다.
sendApi는 자신이 가지는 dto 타입과 일치하는 요청을 sendModule을 통해 입력받고 이에 대한 처리결과만을 반환 하면된다
결론
dto를 단순히 메소드간의 통신을 위한 요소로만 생각하지 않고 어떠한 task를 처리하기 위한 중심으로 보고 의존성에 대한 개념을 바꾸어 봤다.
각 함수들은 도메인(dto)에 대해 의존하고 template 함수들은 dto의 구현체이며 sendApi는 해당 dto 구현체를 처리하기 위한 역할을 수행한다.
그리고 unitModule과 sendApi 사이의 느슨한 결합도를 유지하기 위해 sendModule을 구현했다.
해당 모듈은 message가 아닌 dto의 타입을 기준으로 Publisher/Subscriber(Pub-Sub) 패턴을 구현한다.
