controller, service, repository 그리고 쪼개기

ohbin Kwon·2022년 3월 27일

인간의 인지 용량은 한정되어 있다.

권력도 3권분립이 되어있고, 조직은 계층적이다. 이처럼 인간은 한번에 다수를 처리하기 보다, 어느정도 추상화되고, 캡슐화된것을 처리하는 것을 능률적이라 생각하고 그렇게 행동해왔다.

코드를 구조화 할 때도 같다.
메인(엔트리 포인트)이 있고, 메인은 각 모듈들을 임포트 한다. 여기서 인간이 그러했던것 처럼 역할을 나눈다(디펜던시 트리).

문제는 잘 쪼개지 않으면, 우리는 한정된 인지용량에서 효율적으로 일하는게 아니라, 오히려 다른 부분들을 계속해서 신경쓰게 되는 비효율적인 환경(의존성이 높은 환경)에서 일하게 된다. 그래서 잘쪼개야 한다(의존성을 줄여야 한다).

구조화

코드베이스가 커질 수록 이러한 구조화(쪼개기)는 유의미하다. 코드의 결합도와 응집도를 높여, 코드의 추상화와 캡슐화를 이끌어 낸다. 이러한 구조화를 통해 코드는 위계를 가지게 된다(트리모양).
책은 목차를 가지고 있는데, 코드도 이런 목차를 파일을 이용해 나타낸다.

구조화를 할때 연역적으로 접근하기 보다, 구조를 파악하고 역할을 나눠야한다. 여기서는 도메인 위주의 설계를 해보고자 한다.

폴더 내부 파일은 같은 도메인을 가진다.
https://github.com/goldbergyoni/nodebestpractices/blob/master/sections/projectstructre/breakintcomponents.md#good-structure-your-solution-by-self-contained-components
도메인 내부에서 service와 respository는 분리한다.
repository(또는 persistency)와 service는 다른 이유로 변한다. service는 고객을 위한 서비스 로직에 의해 변하고, repository는 의존하는 db에 의해 변한다. service와 repository를 분리하지 않으면, 서비스 로직이 변했을때, 우리는 db로직을 매번 바꿔야하고, 반대로 db가 바뀌면, 수백개의 서비스로직을 변경해야한다. 같은 이유로 바뀌는 것들을 모으면 의존성을 줄일 수 있다. 모든 것은 의존성을 줄이기 위함이다.

의존성

그렇다면 의존성이란 뭘까?
예를 들어, 내가 nestjs framework를 사용한다면, 편리하게 다른 사람의 아이디어를 사용할 수 있고, 외부의 발전이 곧 나의 발전이 되기에 아주 효율적이라 할 수 있다.(물론 효율적으로 사용했을때)
이렇게 nestjs는 프레임워크 언어를 강제해주고(구속), 생각해야할 것을 한정해 주고(표준, 규율), 인터페이스만 보면되고(캡슐화, 추상화), 베스트 프랙티스들도 존재하기에, 코드 작성을 쉽게 해준다.
이처럼 의존성은 많은 장점을 가지고 있다. 하지만 한번 사용하면 해당 의존성에 구속되고, 해당 의존성을 잘 활용하지못하면 독이 될 수 있다는 단점이 있다.

도메인

코드는
1. 외부상태 (state)(db ,파일, 캐시, 전역변수 등의 영속성): Read
2. 입력(request or params)
3. 출력(response or return): 외부상태에 따라 출력이달라지지 않도록
4. 부수효과(side effect, mutation): Create, update, delete
의 4가지로 나뉜다.

여기서 domain 모델에는 순수함수를 사용한다. 어디에 의존하지 않도록, 입력에 의해서만 출력이 바뀌도록 해야한다.(domain 모델은 비즈니스 모델(돈)이다. 이게 지켜졌으면 좋겠다하는 사용자의 요구사항이기 때문이다.)
db에서 가져오는것은 외부상태에 의존하고, 도메인 모델은 어디에 의존하지 않는다. 따라서 디비없이 테스트가 가능하도록 해야한다.
cf) di를 해야하는 이유
context api는 의존성주입 도구 이다.
의존성이 바뀌었을때, 300곳을 다바꿔야한다 di를 안하면, 그런데 di를 하면 다 바꾸지 않아도 된다.

예시

1.프로필

2.회원가입,로그인,로그아웃,탈퇴(회원가입, 로그인도 create이다)(회원가입은 유저를 create, 로그인은 인증정보를 create)(근데 create라서 같은 도메인이아니라 같은 정책을 공유하기때문에, 회원가입과 로그인 비밀번호바뀌면 둘다 바뀜)(도메인은 정책이 바뀌어야 바뀌는것)(도메인 모델이 바뀔때 영속성은 안바뀔수있다)(기획이 바뀔때 바뀌는것이 도메인 모델이다)(도메인 로직은 어디에도 의존하지 않지만, 다른것들은 모두 도메인에 의존하므로 db등이 바뀔 수 있다.)(repository는 도메인 로직에 의존)(의존성의 방향!)(A가 바뀔 때 B도 바꿔야 하면, B가 A를 의존하고 있다. import) ⇒ 비밀번호 8자리에서 12자리로 바뀌면(정책(도메인로직)이 바뀌면) repository 등이 바뀌지만, db를 바꾼다고 정책, 도메인 로직이 바뀌진 않는다

3.팔로우,팔로잉

4.카트

이 네가지는 분리해야한다.

도메인이 다르기때문에 유저를 보는 관점이 다르고 역할이 다르다(회원가입 정책과 팔로우 정책은 다르기때문에)
영속성에서는 연결이 되어 있지만, 도메인 관점에서는 연관이 없다(연관이 있다면 유저아이디정도..?)

결국 의존성을 제대로 설정하는것! 잘 쪼개는것!이 핵심이다.