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

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

깨진 유리창 하나를 방치해 두면, 그 지점을 중심으로 범죄가 확산되기 시작한다는 이론으로, 사소한 무질서를 방치하면 큰 문제로 이어질 가능성이 높다는 의미를 담고 있다

• 품질이 떨어진 코드에서 작업할 때 더 낮은 품질의 코드를 추가하기가 쉽다.

• 코딩 규칙을 많이 어긴 코드에서 작업할 때 또 다른 규칙을 어기기도 쉽다.

• 지름길을 많이 사용한 코드에서 작업할 때 또 다른 지름길을 추가하기도 쉽다.

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

• 유스케이스 간에 입출력 모델을 공유하게 되면 유스케이스들 사이에 결함이 생긴다.

• 단일 책임 원칙에서 이야기하는 변경할 이유를 공유하는 것이다. 출력 모델을 공유하는 경우에도 마찬가지다.

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

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

• 도메인 엔티티를 유스케이스의 입출력 모델로 사용하면 도메인 엔티티가 유스케이스에 결합된다.

• 간단한 생성이나 업데이트 유스케이스에서는 유스케이스 인터페이스에 도메인 엔티티가 있는 것이 괜찮을지도 모른다. 데이터베이스에 저장해야 하는 바로 그 상태 정보가 엔티티에 있기 때문이다. 하지만 유스케이스가 단순히 데이터베이스의 필드 몇개를 업데이트하는 수준이 아니라 더 복잡한 도메인 로직을 구현해야 한다면(도메인 로직의 일부를 풍푸한 도메인 엔티티로 위임할 수도 있으니), 유스케이스 인터페이스에 대한 전용 입출력 모델을 만들어야 한다.

인커밍 포트 건너 뛰기

• 인커밍 포트가 없으면 도메인 로직의 진입점이 불분명해진다.

• 인커밍 포트를 제거함으로써 인커밍 어댑터와 어플리케이션 계층 사이의 추상화 계층을 줄였다. 보통 추상화 계층을 줄이는 것은 괜찮게 느껴진다. 하지만 인커밍 포트는 애플리케이션 중심에 접근하는 진입점을 정의한다. 전용 인커밍 포트를 유지하면 훈눈에 진입점을 식별할 수 있다. 이는 새로운 개발자가 코드를 파악할 때 특히 더 도움 된다.

• 또 다른 이유는 아키텍처를 쉽게 강제할 수 있다. 인커밍 어댑터에서 호출할 의도가 없던 서비스 메서드를 실수로 호출하는 일이 절대 발생할 수 없다

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

• 애플리케이션 서비스가 없으면 도메인 로직을 둘 곳이 없다.

• 인커밍 어댑터와 아웃고잉 어댑터 사이에 모델을 공유해야 하며, 도메인 모델을 입력 모델로 상요하는 케이스가 된다. 아울러 애플리케이션에 코어에 유스케이스라고 할 만한 것이 없어진다.