CH06 영속성 어댑터 구현하기

영속성 어댑터 의존성 역전

마찬가지로 어플리케이션이 정의한 인터페이스 명세에 맞게 어댑터와 통신한다. 의존성 역전이 이뤄진 모습이다.

왜 port 가 Out 이라는 거지?(헥사고날 아키텍처의 in, out 의미)

이게 처음에 나를 혼란스럽게 했다. 왜냐면 코드를 실제로 구현하기 전엔 데이터의 방향으로 인식했기 때문이다. 영속성 어댑터를 통해서 데이터를 로드도 하기 때문에 데이터의 방향이 꼭 out 은 아니다.

책에서 말하는 out 인 이유는 호출의 방향이다. 즉, 어플리케이션은 영속성 어댑터를 호출하는데(어플리케이션 -> 영속성 어댑터) 반대로 영속성 어댑터는 어플리케이션을 호출하지 않기 때문이다.

in port 도 보면 웹 어댑터가 어플리케이션의 유스케이스를 호출하는데 이 두 가지에서 알 수 있는 것은 헥사고날 아키텍쳐에서 in, out 은 데이터의 흐름이라기 보단 호출의 방향성을 의미한다.

포트 인터페이스 나누기, ISP

DDD 세레나데 수강 했을 때도 그렇고 일반적으로 구현했던 Repository 인터페이스에는 수많은 메소드들이 정의되어 있다. 이 '넓은 인터페이스'를 도식화한 그림이 아래와 같다.

AccountRepository 에 n개의 메소드들이 정의되어 있을텐데 이 모든 메소드를 SendMoneyService 가 사용하진 않을 것이다. 즉, '넓은 인터페이스'에 의존함으로써 불필요한 의존이 발생한 것인데 이 포인트에서 ISP 가 적용될 수 있다.

ISP를 적용하면 아래와 같이 쪼개어질 수 있다.(예제 코드에 아래와 같이 구현되어 있다)

좁은 포트를 만드는 것을 책에서 말하길 '플러그 앤드 플레이(plug-and-play)' 라고 한다. 서비스 코드를 만들 때 필요한 포트에 그저 '꽂기만' 하면 된다. 구체적으로 말하자면 유스케이스의 구현체에서 out port 를 사용할 때 필요한 port 에(포트가 잘 나뉘어져 있으니) 꽂기만 하면 된다는 것이다.

영속성 어댑터 나누기

웹 어댑터 부분에서 웹 어댑터를 나눈다는 것과 동일한 맥락에서 영속성 어댑터 역시 기능을 기준으로 아래와 같이 나눌 수 있다.