아마도 Nest에서 Service단에서 DB에 바로 접근하는 것은 좋지 못한 것 같다.
실제로 회사에서 .NET CORE로 백엔드 서버를 만들 때, 이곳 저곳에서 분별없이 DB에 접근을 하다보니 여러가지 문제가 있었다. 실제 가장 문제가 되었다고 느끼는 부분은
1. 하나의 함수, 변수를 수정할 때 사이드 이펙트가 생길 가능성이 높다.
처음에는 내가 만든 함수가 어떤 변수를 사용하는지, 어느 곳에서 호출하는지 고려하고 기능의 추가 혹은 수정이 가능했지만 프로젝트가 커지면서 점점 예상치 못한 문제들이 발생하기 시작했다. 특히 DB와 관련된 기능들은 되돌릴 수 없는 문제를 야기할 수 있기 때문에 특히나 조심해야 함을 느꼈다.
즉 개체간의 결합도를 낮추는 작업이 필요하다.
2. 데이터 로직과 비즈니스 로직이 분별이 되지 않는다.
실제로 서비스 단의 각 함수에서 비즈니스 레이어의 로직, 데이터 관리 로직, DB 연동 로직이 모두 쓰이다 보니 쓸데 없이 코드의 양이 너무 많아지고, 이해하기도 어려워지고 있다는 생각이 들었다.
이 문제를 가장 크게 느꼈던 일이 있었는데, 바로 중국 출장이었다. 나 혼자 백엔드를 담당하고 있었는데, 출장을 가게 되어 미리 VDI를 신청했었다. 하지만 보안상의 이유로 거절이 되었고 그저 서비스에 문제가 없길 기도할 수 밖에 없는 상황이 되었다.
하지만 당연하다는 듯이 문제는 발생했고, 전화로 사무실에 있는 선배님께 전화를 걸어 아바타 코딩으로 문제를 고칠 수 있었다.. 만약 내가 코드를 직관적으로 짰었다면 간단한 문제였기 때문에 사무실에 있던 선배들이 쉽게 고치지 않았을까? 하는 아쉬움이 굉장히 컸었다.
데이터 로직과 비즈니스 로직을 나누기만 해도 훨신 간결한 코드가 되지 않을까?
그래서 Nest 프로젝트에서 적용할 것이 Repository Pattern이다.
Repository 패턴을 통해서 서비스 로직과 데이터 로직을 분리하고, 여러 데이터 저장소를 추상화하여 중앙 집중 처리 방식을 구현하는 것이 목표다. 출처가 다른 데이터도 Repository를 통해서 이용할 수 있게 한다.
위 이미지의 구조를 프로젝트의 기본 골조로 한다. 이 구조만 지킨다면 기능적으로도, 가시적으로도 조금 더 클린코드에 근접해지지 않을까 생각한다. 아마도.