클린 아키텍처 유지보수를 망치는 습관 3 가지

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

깨진 창문 이론

어떤 것이 멈춘 것처럼 보이고, 망가져 보이고, 관리되지 않는다고 여겨지면 인간의 뇌는 이를 더 멈추고, 망가뜨리고, 관리하지 안 해도 된다고 생각하게 된다. (Philp Zimbardo)

망가진 자동차와 안 망가진 자동차를 주차해두고 실험해 본 결과 사람들은 망가져 있는 자동차를 더 망가트리거나 부품들을 도난했다. 
반대로 안 망가진 자동차를 그대로 유지가 되는 결과가 있었다.
하지만, 안 망가진 자동차의 창문을 깨트리고 다시 실험을 했을 때, 바로 망가져버리는 결과가 있었습니다.

 

→ 이러한 실험 결과를 통해 알 수 있는 점은 사람은 심리적으로 망가져 있는 것을 보면 아닌 것에 비해 더 막 다루어도 된다고 생각하는 경향이 있다.

 

코드 작업과 깨진 창문과의 관계

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

 

문제 1 : 유스케이스 간 모델 공유

 

2 개의 유스케이스가 같은 입력 모델을 공유하면 아래와 같은 문제가 발생합니다.

 

입력 모델 공유로 인해, SendMoneyUseCase와 RevokeActivityUseCase가 결합되어, 하나의 유스케이스 요구사항 변경으로 SendMoneyCommand 입력 모델을 변경하면 다른 유스케이스에도 변경을 해야 합니다.

 

→ 단일 책임 원칙에 어긋나는 행위

 

유스케이스 간 입출력 모델을 공유해도 되는 경우는 유스케이스들이 기능적으로 묶여 있을 때만 유효하다. 특정 세부사항을 변경할 경우 두 유스케이스 모두에 영향을 주고 싶을 때 공유할 수 있다. (기능적으로 묶여 있으며, 중복 코드를 방지할 수 있음)

 

처음에 입축력 모델이 비슷해 보이더라도 각 유스케이스를 입출력 모델을 분리하는 것이 좋다.

 

문제 2: 도메인 엔티티를 입출력 모델로 사용

 

도메인 엔티티를 입력 모델로 사용하게 되면, 인커밍 포트는 도메인 모델과 의존성을 가지게 됩니다.

이러한 상황은 해당 도메인 모델에 있어 변경할 이유가 또 생기게 되어 좋지 않은 방법입니다.

• 입력 모델에 추가되어야 할 필드가 생기면 도메인 모델에 불필요한 추가가 발생합니다.
• 도메인 로직과 입출력 모델에 관한 내용이 섞이게 되어 한눈에 구분하기 어려워집니다.

 

문제 3: 인커밍 포트 건너뛰기

 

인커밍 포트 같은 경우는 인커밍 어댑터와 애플리케이션 서비스 중간에 위치한 포트입니다.

의존성 흐름이 애플리케이션으로 흐르고 있어, 의존성 역전을 일으키는 요소가 아니며, 필수적인 요소는 아닙니다.

인커밍 포트를 사용하지 않으면, 위 사진처럼 추상화 계층이 제거되어 코드 작업이 적어지는 장점이 존재합니다.

 

하지만,

인커밍 포트를 제거하게 되면 특정 유스케이스를 구현하기 위해 어떤 서비스 메서드를 호출해야 할지 애플리케이션 서비스의 내부 동작을 파악해야 하는 단점이 있습니다. (서비스 구현체를 보면 어떤 메서드가 있는지 한 눈에 알기 어렵다.)

 

---

결론

1. 유스케이스 간의 입출력 모델을 공유하기보다는 맞춤별 입출력 모델을 구현하는 것이 좋다.
   • 단일 책임 원칙 위반
2. 도메인 모델을 입출력 모델로 사용하는 것은 좋지 않다.
   • 도메인 모델은 도메인의 상태와 로직만을 담당해야 한다. 입출력 기능까지 더해지면 변경되어야 할 이유가 추가로 생겨 좋지 않다.
   • 사용자가 필요로 하는 데이터가 전달하는 것이 좋다.
3. 인커밍 포트로 애플리케이션 진입점 명확히 하기