11. 의식적으로 지름길 사용하기
- 지름길을 방지하기 위해서는 먼저 지름길 자체를 파악해야 한다.
- 이 정보만 알고 있어도 우발적으로 사용되는 지름길을 수정할 수 있다.
- 정당한 지름길이라면 지름길의 효과를 의식적으로 택할 수도 있다.
왜 지름길은 깨진 창문 같을까?
- 코드 작업을 할 때 ‘깨진 창문 이론’이 적용될 수 있다.
- 품질이 떨어진 코드에서 작업할 때 더 낮은 품질의 코드를 추가하기가 쉽다.
- 코딩 규칙을 많이 어긴 코드에서 작업할 때 또 다른 규칙을 어기기도 쉽다.
- 지름길을 많이 사용한 코드에서 작업할 때 또 다른 지름길을 추가하기도 쉽다.
깨끗한 상태로 시작할 책임
- 가능한 한 지름길을 거의 쓰지 않고 기술 부채를 지지 않은 채로 프로젝트를 깨끗하게 시작하는 것이 중요하다.
- 소프트웨어 프로젝트는 대개 큰 비용과 장기적인 노력이 필요하기에 깨진 창문을 막는 것이 개발자들의 막대한 책임이다.
- 그러나 때로는 지름길을 취하는 것이 실용적일 때도 있다.
- 그리 중요하지 않은 부분이거나
- 프로토타이핑 작업 중이거나
- 경제적인 이유
- 의도적인 지름길에 대해서는 세심하게 잘 기록해둬야 한다.
유스케이스 간 모델 공유하기
- 4장에서 유스케이스마다 다른 입출력 모델을 가져야 한다고 했다.
- 두 유스케이스가 입력 모델을 공유하면 유스케이스 간의 결합이 발생하기 때문이다. (’변경할 이유’를 공유하게 되는 것)
- 유스케이스들이 기능적으로 묶여있을 때 입출력 모델을 공유하는 것이 유효할 때도 있다.
- 두 유스케이스가 독립적으로 진화해야 한다면 처음엔 똑같은 입출력 클래스를 복사 하더라도 일단 분리해서 시작해야 한다.
도메인 엔티티를 입출력 모델로 사용하기
- 도메인 엔티티를 인커밍 포트 인터페이스의 입출력 모델로 사용하는 경우
- ex)
Account를 SendMoneyUsecase의 파라미터나 반환 값으로 사용
- 인커밍 포트가 도메인 엔티티에 의존성을 가지면 도메인 엔티티는 변경할 또 다른 이유가 생기는 것이다.
- ex) 현재 도메인 엔티티에 존재하지 않는 정보를 유스케이스가 필요로 한다면, 도메인 엔티티에 필드를 추가하고 싶어질 수도 있다.
- 이 지름길은 시간이 지나면서 복잡한 도메인 로직 괴물이 되어가기에 위험하다.
- 만약 처음에 도메인 엔티티를 입력 모델로 사용했다면 독립적인 입력 모델로 교체해야 하는 시점을 잘 파악해야 한다.
인커밍 포트 건너뛰기
- 아웃고잉 포트와 달리 인커밍 포트는 필수적인 요소는 아니다.
- 인커밍 포트 없이 Controller가 Service에 직접 접근할 수 있다.
- 인커밍 포트를 제거함으로써 어댑터와 애플리케이션 계층 사이의 추상화 계층을 줄였다.
- 인커밍 포트는 애플리케이션 중심에 접근하는 진입점을 정의한다.
- 인커밍 포트가 없다면 특정 유스케이스를 구현하기 위해 어떤 서비스 메서드를 호출해야 할지 알기 위해 애플리케이션 내부 동작을 더 잘 알아야 한다.
- 인커밍 포트를 사용하면 아키텍처를 쉽게 강제할 수 있다.
- 인커밍 어댑터가 인커밍 포트만 호출하도록 강제할 수 있다.
- 인커밍 어댑터에서 다른 서비스를 실수로 호출하는 일이 절대 발생할 수 없다.
- 애플리케이션 규모가 작거나 인커밍 어댑터가 하나밖에 없는 애플리케이션은 인커밍 포트가 없는 것이 편하다.
- 하지만 규모는 계속 커질 것이고, 인커밍 어댑터가 언제까지 하나일지는 알 수 없다.
애플리케이션 서비스 건너뛰기
- 유스케이스에서 애플리케이션 계층 없이 바로 영속성 계층에서 인커밍 포트 인터페이스를 구현할 수도 있다.
- ex)
RegisterAccountUsecase 구현체를 AccountPersistenceAdapter로 만듦
- 애플리케이션 서비스를 건너뛰면 간단한 CRUD에선 정말 구미가 당기는 방법이다.
- 하지만 이 방법은 인커밍 어댑터와 아웃고잉 어댑터 사이에 모델을 공유해야 한다.
- 도메인 엔티티를 입력 모델로 사용하는 케이스가 되는 것
- 애플리케이션 코어라고 할 만한 것이 없어진다.
- 유스케이스가 점점 복잡해지면 도메인 로직이 흩어져서 유지보수가 어려워질 것이다.