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

깨진 유리창의 법칙과 같이 코드에서도 한 번 코딩 규칙을 어긴다면 또 다른 규칙을 어기기 쉽다. 따라서 이번 장은 지름길을 파악하는 장이다.

🔗 유스케이스 간 모델 공유

4장에서 유스케이스마다 다른 입출력 모델(입력 파라미터 타입과 반환값의 타입이 달라야 함)을 가져야 한다고 말했다. 만약 유스케이스 간 모델을 공유한다면, 결합된다는 것이고 모델을 수정하면 유스케이스 모두 영향을 받는 다는 것을 의미한다.

유스케이스 간 입출력 모델을 공유하는 것은 유스케이스들이 기능적으로 묶여 있을 때 유효하다. 실제로 입출력 모델이 변경되면 유스케이스 모두 영향을 받아야 한다면 사용해도 된다.

🔗 도메인 엔티티를 입출력 모델로 사용

인커밍 포트가 도메인 엔티티에 의존할 때 도메인 엔티티(Account)에 존재하지 않는 필드가 인커밍 포트(SendMoneyUseCase)에서 필요하다면, 도메인 엔티티를 변경할 수도 있다. 하지만 유스케이스 변경이 도메인 엔티티까지 전파되지 않아야 하기에 서로 의존하지 않는 것이 좋다.

🔗 인커밍 포트 건너뛰기

아웃고잉 포트는 애플리케이션 계층과 아웃고잉 어댑터 사이의 의존성을 역전시키기 위해 필수 요소지만, 인커밍 포트는 필수 요소는 아니다. 따라서 인커밍 포트를 제거해 추상화 계층을 줄일 수도 있다.

인커밍 포트로 진입점을 한눈에 식별할 수 있고, 아키텍처를 쉽게 강제할 수 있으므로 건너뛰는 것은 좋지 않다.

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

애플리케이션 계층을 뛰어넘고 아웃고잉 어댑터가 직접 인커밍 포트를 구현할 수 있다.

이 방법은 인커밍 어댑터와 아웃고잉 어댑터 사이에 모델을 공유해야 하며, 이는 도메인 모델을 입력 모델로 사용하는 케이스가 된다. 또한 도메인 로직이 흩어져 찾기 힘들어진다.