지름길을 피하기 위해서는 지름길 자체를 파악해야 한다.
지름길
- 유스케이스 간 모델 공유하기
- 도메인 엔티티를 입출력 모델로 사용하기
- 인커밍 포트 건너뛰기
- 애플리케이션 서비스 건너뛰기
11-1. 왜 지름길은 깨진 창문 같을까?
깨진 유리창 하나를 방치해 두면, 그 지점을 중심으로 범죄가 확산되기 시작한다
- 품질이 떨어진 코드에서 작업할 때 더 낮은 품질의 코드를 추가하기 쉽다.
- 코딩 규칙을 많이 어긴 코드에서 작업할 때 또 다른 규칙을 어기기도 쉽다.
- 지름길을 많이 사용한 코드에서 작업할 때 또 다른 지름길을 추가하기도 쉽다.
11-2. 깨끗한 상태로 시작할 책임
가능한 한 지름길을 거의 쓰지 않고 기술 부채를 지지 않은 채로 프로젝트를 깨끗하게 시작하는 것이 중요하다.
- 깨진 창문을 막는 것이 소프트웨어 개발자들의 아주 막대한 책임이다.
- 의도적인 지름길은 세심하게 잘 기록해두어야 한다.
- 더 실용적일 경우: 전체에서 중요하지 않은 부분, 프로토타이핑 작업, 기타 경제적 이유 등
11-3. 유스케이스 간 모델 공유하기
유스케이스마다 입력 파라미터 타입과 반환값의 타입이 달라야 한다.
유스케이스 간 모델을 공유한다면
- 다른 유스케이스와의 결합이 생긴다.
- 두 유스케이스가 변경할 이유를 공유한다.
허용하는 경우
- 유스케이스들이 특정 요구사항을 공유할 때
- 특정 세부사항을 변경할 경우 두 유스케이스에 모두 영향을 주고 싶다.
두 유스케이스가 독립적으로 진화해야한다면, 똑같은 입출력 모델을 복사하더라도 분리해라.
11-4. 도메인 엔티티를 입출력 모델로 사용하기
도메인 엔티티를 포트의 입출력 모델로 사용한다면
- 도메인 엔티티가 유스케이스에 결합된다.
- 인커밍 포트가 도메인 엔티티에 의존한다 → 유스케이스의 변경이 도메인 엔티티에 전파될 수 있다. → 도메인 엔티티에 변경할 이유가 추가되었다.
단순한 CRUD의 역할이 아닌 더 복잡한 도메인 로직을 구현해야 한다면 전용 입출력 모델로 교체해야 한다.
11-5. 인커밍 포트 건너뛰기
인커밍 포트는 의존성 역전에 필수적인 요소는 아니다.
인커밍 어댑터가 애플리케이션 서비스에 직접 접근한다면
도메인 로직(애플리케이션 코어의 진입점이 불분명해진다.
- 인커밍 포트: 애플리케이션 코어에 접근하는 진입점
- 바로 서비스에 접근한다면 애플리케이션의 내부 동작에 대해 더 잘 알아야 한다.
- 아키텍처를 쉽게 강제할 수 있다. (10장 아키텍처 경계 강제하기 = 올바른 의존성 방향 유지)
- 10-2장 service 구현체를 package-private으로, usecase 인터페이스를 public으로 열어둔다.
11-6. 애플리케이션 서비스 건너뛰기
간단한 CRUD에서 애플리케이션 서비스가 도메인 로직 없이 바로 요청을 영속성 어댑터에 전달하는 경우
애플리케이션 서비스를 건너뛴다면
- 영속성 어댑터가 직접 유스케이스를 구현한다.
- 인커밍 어댑터와 아웃고잉 어댑터가 모델을 공유한다. → 11-4장 도메인 엔티티를 입출력 모델로 사용하기
- 시간이 지나 유스케이스가 복잡해지면 도메인 로직을 영속성 어댑터가 구현하게 되고, 도메인 로직이 흩어진다.
11-7. 유지보수 가능한 소프트웨어를 만드는 데 어떻게 도움이 될까?
- 경제적인 관전에서 지름길이 합리적일 경우도 있다.
- 유스케이스가 단순한 CRUD 상태에서 벗어나는 시점에는 지름길을 더 유지보수하기 좋은 아키텍처로 대체해야 한다.
- 왜 특정 지름길을 선택했는가에 대한 기록을 남기자.
