[만들면서 배우는 클린 아키텍처] 11. 의식적으로 지름길 사용하기

지름길을 방지하기 위해서는 먼저 지름길 자체를 파악해야 한다. 우발적으로 사용되는 지름길을 인식하고 수정할 수 있고 정당한 지름길이라면 지름길의 효과를 의식적으로 선택할 수 있다.

왜 지름길은 깨진 창문 같을까?

깨진 창문 이론이 코드 작업에 적용 될 때의 의미

- 품질이 떨어진 코드에서 작업할 때 더 낮은 품질의 코드를 추가하기가 쉽다.

- 코딩 규칙을 많이 어긴 코드에서 작업할 때 또 다른 규칙을 어기기도 쉽다.

- 지름길을 많이 사용한 코드에서 작업할 때 또 다른 지름길을 추가하기도 쉽다.

깨끗한 상태로 시작할 책임

가능한 한 지름길을 거의 쓰지 않고 기술 부채를 지지 않은 채로 프로젝트를 깨끗하게 시작하는 것이 중요하다. 지름길이 몰래 스며드는 순간 더 많은 지름길을 끌어들이기 때문이다.

 

프로토타이핑 작업 중이거나, 경제적인 이유로 때로는 지름길을 취하는 것이 더 실용적일 때도 있다.

이런 의도적인 지름길에 대해서는 잘 기록해둬야 한다. 의도적으로 추가됐다는 사실을 알기 때문에 깨진 창문 이론의 영향을 줄일 수 있다.

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

유스케이스가 같은 입력 모델을 공유하는 경우

 

RevokeActivityUseCase와 SendMoneyUseCase 가 결합된다.

 

유스케이스들이 기능적으로 묶여 있을 때는 유효하다. 이 경우 특정 세부사항을 변경할 경우 실제로 두 유스케이스 모두에 영향을 주고 싶은 것이다.

 

서로 영향 없이 독립적으로 진화해야 한다면 입출력 클래스를 분리해야 한다.

비슷한 개념의 유스케이스 여러 개를 만든다면 유스케이스를 독립적으로 진화할 필요가 있는지 주기적으로 확인하고, 만약 그렇다면 입출력 모델을 분리해야 한다.

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

인커밍 포트는 도메인 엔티티에 의존성을 갖고 있다.

엔티티에는 존재하지 않는 정보를 유스케이스가 필요로 하게 되면 다른 도메인이나 다른 바운디드 콘텍스트에 저장되어야 하지만 이미 유스케이스 인터페이스에서 사용하고 있는 도메인 엔티티에 새로운 필드를 추가하고 싶은 생각이 들게 된다.

 

유스케이스가 복잡한 도메인 로직을 구현해야 한다면 유스케이스 인터페이스 전용 입출력 모델을 만들어야 한다.

 

인커밍 포트 건너뛰기

아웃고잉 포트는 애플리케이션 계층과 아웃고잉 어댑터 사이의 의존성을 역전시키기 위해 필수 요소이지만 인커밍 포트는 인커밍 어댑터가 포트 없이 애플리케이션 서비스에 직접 접근할 수 있다.

 

인커밍 포트는 애플리케이션 코어에 접근하는 진입점을 정의한다. 포트를 제거하면 유스케이스를 구현하기 위해 어떤 서비스 메서드를 호출해야 할지 알기 위해 애플리케이션 내부 동작을 더 잘 알아야 한다.

 

인커밍 포트를 유지하면 아키텍처를 강제하는 옵션을 이용해 인커밍 어댑터가 애플리케이션 서비스가 아닌 인커밍 포트만 호출하게 할 수 있다. 그렇게 하면 인커밍 어댑터에서 호출할 의도가 없던 서비스 메서드를 실수로 호출하는 일이 발생할 수 없다.

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

아웃고잉 어댑터는 직접 인커밍 포트를 구현해서 애플리케이션 서비스를 대체한다.

 

간단한 CRUD 유스케이스에서는 영속성 어댑터가 직접 유스케이스를 구현하게 할 수 있다. 하지만 인커밍 어댑터가 아웃고잉 어댑터 사이에 모델을 공유해야 한다. 이 경우 도메인 모델을 입력 모델로 사용하고 있다.

 

시간이 지남에 따라 유스케이스가 복잡해지면 도메인 로직을 아웃고잉 어댑터에 추가하고 싶어 지게 된다.

유지보수 가능한 소프트웨어를 만드는 데 어떻게 도움이 될까?

간단한 CRUD 유스케이스에서는 지름길을 선택하는 것이 더 합리적일 수 있다. 유스케이스가 복잡해지는 시점이 언제인지에 대해 팀이 합의하는 것이 매우 중요하다.

어떤 경우든 아키텍처에 대한, 왜 특정 지름길을 선택했는가에 대한 기록을 남겨서 이후에도 이 결정에 대해 다시 평가할 수 있게 해야 한다.