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

소프트웨어는 하드웨어에 비해 쉽게 변경할 수 있기 때문에, 어떤 떄는 지름길을 먼저 취하고 나중에 고치는 것이 더 경제적일 수 있다.

지름길은 깨진 창문과 같다.

• 품질이 떨어진 코드에서 작업할 때 더 낮은 품질의 코드를 추가하기 쉽다.
• 코딩 규칙을 많이 어긴 코드에서 작업할 때 또 다른 규칙을 어기기 쉽다.
• 지름길을 많이 사용한 코드에서 또 다른 지름길을 추가하기 쉽다.

→ 레거시 코드 일 수록, 코드 품질이 낮아진다.

깨끗한 상태로 시작할 책임

• 소프트웨어 프로젝트는 대개 큰 비용이 들고 장기적인 노력을 필요로 하기 때문에 깨진 창문을 막아야 한다.
• 의도적인 지름길에 대해서는 세심하게 기록해두어야 한다.

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

유스케이스 간에 입출력 모델을 공유하게 되면 유스케이스들 사이에 결합이 생긴다. 즉 입출력 모델이 변경되면, 이에 의존하고 있는 유스케이스에 변경의 여지가 생긴다.

 

유스케이스 들이 기능적으로 묶여 있을 때는 입출력 모델을 공유하는 것은 괜찮다. 즉, 특정 세부 사항을 변경할 경우, 실제로 두 유스케이스 모두에 영향을 주고 싶을 때를 말한다.

 

하지만, 유스케이스가 독립적으로 진화해야 하면, 입출력 모델을 분리하여야 한다.

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

도메인 엔티티가 유스케이스의 입출력 모델이라면, 이는, 도메인 엔티티가 유스케이스에 결합된다.

 

유스케이스가 간단하지 않고, 더 복잡한 도메인 로직을 구현해야 한다면, 유스케이스 인터페이스에 대한 전용 입출력 모델을 만들어야 한다. 이는 유스케이스의 변경이 도메인 엔티티까지 전파되기 때문이다.

인커밍 포트 건너 뛰기

인커밍 포트는 의존성 역전에 필수적이지 않다. 따라서 인커밍 어댑터가 인커밍 포트 없이 애플리케이션 서비스에 직접 접근하도록 할 수 있다.

이를 통해 추상화 계층을 줄여서 괜찮게 느껴질 수 있다.

 

하지만, 인커밍 포트는 애플리케이션 중심에 접근하는 진입점을 정의한다. 전용 인커밍 포트를 통해 한눈에 애플리케이션의 진입점을 식별할 수 있다.

 

또한, 아키텍처를 강제할 수 있다. 인커밍 어댑터가 애플리케이션 서비스가 아닌 인커밍 포트만 호출하는 것은 의도가 없던 서비스 메서드를 실수로 호출하는 것을 방지한다.

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

아웃고잉 어댑터에 있는 AccountPersistenceAdapter 클래스는 직접 인커밍 포트를 구현하여 일반적으로 인커밍 포트를 구현하는 애플리케이션 서비스를 대체한다.

 

하지만 이는, 인커밍 어댑터와 아웃고잉 어댑터 사이에 모델을 공유해야 한다. 이 경우 공유해야 하는 모델이 도메인 모델이 될 수 있다.

 

또한 애플리케이션 코어에 유스케이스가 없어진다. 이는, 어댑터에 구현이 되어있으니, 유지보수하기가 어려워진다.

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

간단한 CRUD 유스케이스에 대해선 지름길의 유혹을 느낄 수 있는데, 이에 대한 가이드 라인을 정해야 한다.

즉, 아키텍쳐에 따라 결정하고, 지름길을 택했을 경우 왜 택했는지 기록을 남겨야 한다.