11. 의식적으로 지름길 사용하기

경제적인 관점에서 지름길을 사용하는게 더 효과적일 수 있다. 지름길을 사용하려면 일단 지름길 자체를 파악해야 한다.

1. 유스케이스 간 모델 공유하기

기본적으로 유스케이스마다 다른 입출력 모델을 가져야 한다. 입력 파라미터의 타입과 반환값의 타입이 달라야 한다는 말이다.

만약 인커밍 포트 인터페이스의 입출력 모델이 같은 모델을 공유할 경우 공유한 모델이 변경될 경우 두 유스케이스 모두 영향을 받는다. 단일 책임 원칙에서 중요하게 생각하는 “변경할 이유”를 공유하게 되는 것이다.

만약 실제로 특정 세부사항을 변경할 경우 실제 두 유스케이스 모두에 영향을 주고 싶은 것이라면 괜찮다.

시작은 공유하더라도 어느 시점에서 유스케이스가 독립적으로 분리가 필요한 시점이라면 분리해야 한다.

1. 도메인 엔티티를 입출력 모델로 사용하기

도메인 엔티티를 유스케이스의 입출력 모델로 사용하면 결합이 발생한다.

유스케이스가 단순히 데이터베이스 필드 몇개를 업데이트 하는 수준으로 간단하다면 괜찮을지도 모르지만 더 복잡한 도메인 로직을 구현해야 한다면 유스케이스 인터페이스에 대한 전용 입출력 모델을 만들어야 한다.

유스케이스의 변경이 도메인 엔티티까지 전파되는걸 바라지 않는다면 말이다.

1. 인커밍 포트 건너뛰기

아웃고잉 포트는 의존성 역전(안쪽으로 흐르게 하기)에 필수 요소이지만 인커밍 포트는 그렇지 않다.

인커밍 어댑터에서 인커밍 포트 없이 애플리케이션 서비스에 직접 접근하도록 할 수 있다.

이 경우 두 계층 사이의 추상화 계층을 줄이면서 괜찮게 느껴질 수 있다.

하지만 인커밍 포트를 통해 애플리케이션 중심에 접근하는 진입점을 정의하지 않으면 특정 유스케이스를 구현하기 위해 어떤 서비스 메서드를 호출해야 하는지 알기 위해 애플리케이션 내부 동작에 대해 더 알아야 한다.

1. 애플리케이션 서비스 건너뛰기

만약 간단한 CRUD 유스케이스에서 애플리케이션 서비스가 도메인 로직 없이 생성, 업데이ㅌ, 삭제 요청을 그대로 영속성 어댑터에 전달하기 때문에 건너뛰고 싶을 수도 있다.

하지만 이렇게 하려면 인커밍 어댑터와 아웃고잉 어댑터 사이에 모델을 공유해야 하는데 공유해야 하는 모델이 도메인 엔티티가 되면서 앞서 이야기한 도메인 엔티티를 입출력 모델로 사용하는 경우가 될 것이다.

또한 시간이 지나서 유스케이스가 점점 복잡해지면 도메인 로직을 그대로 아웃고잉 어댑터에 추가하고 싶은 생각이 들면서 도메인 로직이 흩어져서 찾고 유지보수 하는것이 어려워 진다.