프로젝트가 작을 때에는 지름길의 유혹을 종종 느낄 수 있습니다. 그러나 프로젝트가 커지면 지름길로 인해 유지 보수가 어려워질 수 있기 때문에 지양해야 합니다. 하지만 상황에 맞게 잘 사용한다면 더 좋은 대안이 될 수도 있으며, 지름길을 잘 사용하기 위해서는 지름길이 어떤 영향을 미치는지 파악하고 있는 것이 좋습니다.

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

유스케이스끼리 입출력 모델을 같이 공유해서 사용하는 것을 말합니다. 이는 유스케이스들이 특정 요구사항을 공유하여 기능적으로 묶여 있을 때 사용할 수 있습니다. 즉 특정 세부사항이 변경됨에 따라 의도적으로 두 유스케이스에 모두 영향을 주고 싶은 경우 사용하는 것이죠. 하지만 요구사항이 변경됐을 때 각 유스케이스가 독립적으로 변해야 한다면, 입출력 모델을 공유하지 말아야 합니다.

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

유스케이스에서 입출력 모델을 따로 만드는 대신 도메인 엔티티를 이용하는 것을 말합니다. 간단한 생성 및 업데이트와 같이 외부 어댑터가 도메인을 조작할 필요가 없을 때에는 이런 방법을 사용할 수도 있습니다. 왜냐하면 엔티티에 들어 있는 정보가 DB에 저장해야 하는 정보와 같기 때문이죠.

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

인커밍 포트 건너뛰기

인커밍 포트는 의존성 역전을 위한 필수 요소는 아닙니다. 그래서 인커밍 포트 없이 애플리케이션 서비스에 직접 접근하도록 함으로써 계층 간 추상화 계층을 줄일 수 있습니다.

인커밍 어댑터가 하나 밖에 없을 때는 언커밍 포트가 없는 것이 편할 수 있습니다. 그러나 인커밍 어댑터가 계속 하나일 것이라고 확신할 수 없으므로, 인커밍 포트를 두어 진입점을 명확하게 하는 것이 좋습니다.

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

영속성 어댑터가 직접 유스케이스를 구현하도록 하는 방법입니다. 하지만 이렇게 할 경우 인커밍 어댑터와 아웃고잉 어댑터 사이에 모델을 공유해야 한다는 문제점이 생깁니다. 즉 앞에서 말했던 ‘도메인 엔티티를 입출력 모델로 사용하는’ 경우가 되는 것이죠. 간단한 CRUD인 경우 이렇게 하는 것이 편할 수 있겠지만 CRUD 유스케이스가 복잡해지면 흩어진 도메인 로직을 찾기 어려워집니다.

애플리케이션의 규모가 작을 때에는 비용을 줄이기 위해 지름길을 택하는 것이 합리적일 수도 있습니다. 따라서 지름길을 택할 때에는 왜 선택했는지 기록을 남기고, 단순 CRUD 상태를 벗어나는 시점이 언제인지 팀이 합의하는 것이 중요합니다. 그리고 해당 시점에 지름길을 더 나은 아키텍처로 대체해야 합니다.