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

지름길을 방지하기 위해서는 먼저 지름길 자체를 파악해야 합니다.

소프트웨어는 말랑말랑하기(쉽게 변경될 수 있기) 때문에 지름길을 먼저 취하고 나중에 고치는 것이 더 경제적일 수 있습니다.

 

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

깨진 창문 이론이란?

번호판 없는 차 한 대를 주거환경이 높고 낮은 환경에 주차하였을 때 주거환경이 낮은 곳에서는 24시간이 지나기 전에 중요 부품들이 도난당했으며 주거환경이 높은 곳에서는 일주일 동안 전혀 손을 타지 않았습니다.

하지만 일부로 창문을 깨뜨리자 짧은 시간동안 행인들에 의해 망가졌습니다.

 

이로 2가지를 알 수 있습니다

- 기물 파손이 흔한 동네에서는 방치된 차를 도둑질하거나 망가뜨리는 일이 더 쉽게 일어난다.

- 좋은 동네라도 차의 창문이 깨져있다면 차를 망가뜨리는 일이 쉽게 일어난다.

 

 

이를 코드에 적용하였을 때 많은 코드의 품질이 시간이 가면서 심하게 낮아졌다는 것을 놀라운 일이 아닙니다.

 

깨끗한 상태로 시작할 책임

위에서 깨진 창문의 예시를 보았듯이 가능한 지름길을 거의 쓰지 않고 기술 부채를 지지 않은 채로 프로젝트를 깨끗하게 시작하는 것이 중요합니다.

 

지름길이 때로는 실용적일 때도 있지만 의도적인 지름길에 대해서는 세심하게 잘 기록해둬야 합니다.

 

몇 가지 지름길에 대한 이야기

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

두 개의 유스케이스가 같은 입력 모델을 공유하게 되는 경우에는 단일 책임 원칙에서 이야기하는 '변경의 이유를 공유하는 것입니다.

 

이럴 때는 유스케이스가 독립적으로 진화할 필요가 있는지 주기적으로 질문하며 "예"가 되는 시점에 바로 모델을 분리해야 합니다.

 

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

인커밍 포트가 도메인 엔티티에 의존하고 있는 경우에는 사용자에게 보여주어야 하는 부분 때문에 도메인 코드가 변경될 수 있습니다.

 

점점 더 복잡한 도메인 로직이 구현되어야 한다면 유스케이스 인터페이스에 대한 전용 입출력 모델이 만들어져야 합니다.

 

인커밍 포트 건너뛰기

의존성 역전시킬 필요가 필수가 아니기 때문에 인커밍 포트를 제거함으로써 추상화 계층을 줄이는 것은 괜찮게 느껴집니다.

 

애플리케이션의 규모가 작아 인커밍 어뎁터가 하나밖에 없어 모든 제어 흐름을 인커밍 포트의 도움 없이 단숨에 파악할 수 있다면 인커밍 포트가 없는 것이 편합니다.

 

하지만 애플리케이션 규모가 계속 작게 유지되거나 인커밍 어댑터가 계속 하나밖에 없을 것이라고 확신할 수 있을까요?

 

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

CRUD 유스케이스에서 서비스가 도메인 로직 없이 생성, 업데이트, 삭제 요청을 그대로 영속성 어댑터에 전달합니다.

 

하지만 시간이 지나면서 로직이 추가되면 도메인 로직을 그대로 아웃고잉 어댑터에 추가하고 싶은 생각이 들 것 입니다.

이렇게 되면 도메인 로직이 흩어져 도메인 로직을 찾거나 유지보수하기가 어려워집니다.

 

 

결론

단순한 CRUD 상태에서 벗어나는 시점이 언제인지 팀이 합의하는 것이 제일 중요합니다.

합의를 이루고 나서 지름길은 장기적으로 더 유지보수하기 좋은 아키텍처로 대체할 수 있습니다.