아키텍처 구성

개요

nestjs를 사용해 어떤 것을 만들지 생각하던 중 몇달 전에 제작한 sns service 개인프로젝트가 적은 기간으로 인해 완성도 등에서 아쉬웠다는 생각이 들어 새로 리팩토링한다는 느낌으로 다시 만들어 보기로 결정했다.

Architecture

이전에는 layered 아키텍처를 사용해 서비스를 작성했으나 이번에는 새로 알게된 포트 어댑터 아키텍처를 서비스에 적용해 보기로 결정했다.

Layered Architecture

출처: https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/ch01.html

layered architecture는 가장 널리 알려진 아키텍처 중 하나로 유사한 역할을 가진 코드를 같은 layer로 분리하고 각 layer가 하위 layer만 의존하도록 구성하는 아키텍처이다.

처음 프로젝트 진행 시 사용이유

1. 개발을 공부하면서 business 로직이 가장 중요하다는 점을 많이 듣게 되었고 layered architecture는 계층의 분리를 통해 business 로직을 외부에서 은닉할 수 있다.
2. 각 계층의 역할이 구분되어 응집도가 높은 코드를 작성할 수 있었기 때문에 선택을 했다.

사용 시 느낀 어려움

1. 테스트 코드 작성의 어려움
   service가 repository를 직접 의존하기 때문에 테스트 코드를 작성하기 위해서는 redis나 repository를 mocking하는 작업이 필요했다.
   문제는 redis를 사용할 때 IORedis 라이브러리를 사용했는데 이를 mocking하는 방법을 찾지 못해 테스트 코드 작성을 포기했던 경험이 있다.
2. 서비스의 infra 의존
   business 로직을 가진 서비스 레이어가 infra에 의존하기 때문에 어려움이 발생 할 수 있다.
   만약 처음 db를 MySql을 선택하여 개발을 진행했는데 중간에 mongoDB를 사용하는 것으로 변경하게 된다면 infra의 변경으로 인해 서비스 레이어의 코드를 같이 바꾸는 상황이 발생할 수 있다는 점이 어플리케이션의 유지보수에 문제가 발생 할 수 있다는 생각이 들었다.

Port Adapter Architecture

module의 개발을 port, adapter로 구분해 진행하는 방식이다.
http 통신의 request는 in-port를 통해 서비스에 접근하고 서비스는 out-port를 통해 db에 데이터를 전달하여 서비스에서 나가는 의존성이 없는 것이 장점이다.

이번 프로젝트 선택 이유

1. business 로직의 외부 의존성 분리
   port는 interface로 외부 서비스가 소통하는 통로 역할을 하게되고
   adapter는 port를 통해 service와 소통하는 외부 요소로
   이를 통해 business 로직이 외부 요소에 의존하지 않는 장점이 존재하여 기능 확장 및 유지 보수에 도움이 될 것이라 생각했다.
2. 테스트 코드 작성의 용이성
   위에서 말한 것과 같이 구현체가 아닌 인터페이스인 port를 의존하기 때문에 구현체가 아닌 인터페이스를 mocking하면 되기 때문에 테스트 코드 작성이 편리해 질 것이라 생각했다.