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

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

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

  • 유스케이스마다 다른 입출력 모델을 가져야 한다.
  • 유스케이스가 입출력 모델을 공유하는 것은 단일 책임 원칙에서 이야기하는 ‘변경할 이유’를 공유하는 것이다.
  • 유스케이스 간 입출력 모델을 공유한느 것은 유스케이스들이 기능적으로 묶여 있을 때 유요하다.
    • 이 경우 특정 세부사항을 변경할 경우 실제로 두 유스케이스 모두에게 영향을 주고 싶은 것이다.
  • 두 유스케이스가 서로 간에 미치는 영향 없이 독립적으로 진화해야 한다면 입출력 모델을 공유하는 방식은 지름길이 된다.

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

  • Account 엔티티는 SendMoneyUseCase가 변경할 이유로 추가된다.
    • Account 엔티티에는 존재하지 않는 정보를 유스케이스가 필요로 한다고 생각하면 최종적으로 Account 엔티티에 저장돼 있어야 하는 것이 아니라 다른 도메인이나 다른 바운디드 컨텍스트에 저장돼야 한다.
    • 그럼에도 불구하고 이미 유스케이스 인터페이스에 사용할 수 있기 때문에 Account 엔티티에 새로운 필드를 추가하고 싶다는 생각이 든다.
  • 간단한 생성이나 업데이트 유스케이슨는 유스케이스 인터페이스에 도메인 엔티티가 있는 것이 괜찮을지도 모른다.
  • 하지만 유스케이스가 단순히 데이터베이스의 필드 몇 개를 업데이트하는 수준이 아니라 더 복잡한 도메인 로직을 구현해야 한다면, 유스케이스 인터페이스에 대한 전용 입출력 모델을 만들어야 한다.
  • 이 지름길이 위험한 이유는 많은 유스케이스가 간단한 생성 또는 업데이트 유스케이스로 시작해서 시간이 지나면 복잡한 도메인 로직 괴물이 되어간다는 사실 때문이다.

인커밍 포트 건너뛰기

  • 인커밍 포트는 의존성 역전에 필수적인 요소는 아니다. 그래서 서비스에 직접 접근할도록 할 수 있다.
  • 인커밍 포트를 건너뛰면 안되는 이유
    • 전용 인커밍 포트를 유지하면 한눈에 진입점을 식별할 수 있다.
    • 아키텍처를 쉽게 강제할 수 있다.
      • 인커밍 어댑터에서 호출할 의도가 없던 서비스 메서드를 실수로 호출하는 일이 절대 발생할 수 없다.

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

  • AccountPersistenceAdapter 클래스가 직접 인커밍 포트를 구현해서 애플리케이션 서비스를 대체하는 경우를 말한다.
  • 애플리케이션 서비스를 건너뛰면 안되는 이유
    • 이 방법은 인커밍 어댑터와 아웃고잉 어댑터 사이에 모딜을 공유해야 한다.
    • 도메인 모델을 입력 모델로 사용하는 케이스가 된다.
    • 시간이 지남에 따라 CRUD 유스케이스가 점점 복잡해지면 도메인 로직을 그대로 아웃고잉 어댑터에 추가하고 싶다는 생각이 들 것이다.
      • 이렇게 되면 도메인 로직이 흩어져서 도메인 로직을 찾거나 유지보수하기가 어려워진다.

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

  • 간단한 CRUD 유스케이스에 대해서 전체 아키텍처를 구현하는 것이 지나치제 느껴지기 때문에 지름길의 유혹을 느낄 수 있다.
  • 모든 애플리케이션은 처음에는 작게 시작하기 때문에, 유스케이스가 단순한 CRUD 상태에서 벗어나는 시점이 언제인지에 대해 팀이 합의하는 것이 매우 중요하다.