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

지름길이란 고민없이 있는 그대로 코딩해 OOP와 스프링의 장점을 다 날려버리는 것을 의미한다. 이 책을 보는 사람들은 이 지름길이 옳은 것인지 또는 기술부채를 쌓아가는 것인지 확인해봐야 한다.

 

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

깨진창문이론이란 "어떤 것이 멈춘 것처럼 보이고, 망가져 보이고, [부정적인 형용자를 넣어보자], 혹은 관리되지 않는다고 여겨지면 인간의 뇌는 이를 더 멈추고, 망가뜨리고, [부정적인 형용사를 넣어보자]해도 된다고 생각하게 된다."는 것을 뜻한다. 

• 기물 파손이 흔한 동네에서는 방치된 차를 도둑질하거나 망가뜨리는 일이 더 쉽게 일어난다.
• '좋은' 동네라도 차의 창문이 깨져있다면 차를 망가뜨리는 일이 쉽게 일어난다.
• 침실이 정돈돼 있지 않으면 옷을 옷장에 넣는 대신 바닥에 아무렇게나 던져 놓기 쉽다.
• 괴롭힘이 흔한 집단에서는 괴롭힘이 더 쉽게 일어난다.

이것을 코드에 적용해보자.

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

 

깨끗한 상태로 시작할 책임

위 말처럼 사람은 무의식적으로 깨진 창문 심리의 영향을 받는다. 따라서 기술 부채를 지지 않은 채로 프로젝트를 시작하는 것이 좋다.

 

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

아래 사진은 입출력 모델을 공유하는 예이다. SendMoneyUserCase와 RevokeActivityUseCase둘다 SendMoneyCommand를 의존하고 있다. 이 말은 SendMoneyCommand를 변경하게 되면 2 클래스 모두에게 영향을 미친다는 것이다.

고민해보자!

• 특정 세부사항을 변경 할 경우 실제로 두 유스케이스 영향을 주고 싶을 경우 사용해도 된다.
• 서로 독립적이기 원한다면 기본적으로는 분리시켜 진화시켜야 한다.

 

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

SendMoneyUseCase가 Account를 의존하게 된다면 변경 할 이유가 하나 더 늘었다.

고민해보자!

• 새로운 필드 생성이 필요함.
• Account엔티티에 저장돼 있어야 하는 것이 아니라 다른 모데인이나 다른 바운디드 컨텍스트에 저장돼야 함.
• SendMoneyUserCase는 Account를 입출력으로 사용하고 있기 때문에 추가하고 싶다는 생각이 듦.

위의 경우에서 단순한 생성이나 업데이트는 유스케이스 인터페이스에 도메인 엔티티가 있는 것도 괜찮을지도 모른다. 하지만 데이터베이스 필드 몇 개를 업데이트하는 수준이 아니라 더 복잡한 도메인 로직을 구현해야 한다면, 유스케이스 인터페이스에 대한 전용 입출력 모델을 만들어야 한다.

 

이 지름길이 위험한 이유는 많은 유스케이스가 간단한 생성 또는 업데이트로 시작해서 시간이 지나면서 복잡한 도메인 로직 괴물이 되어간다. 처음에는 도메인 엔티티를 입력모델로 사용했더라도 모데인 모델로부터 독립적인 전용 입력 모델로 교체해야 하는 시점을 잘 파악해야 한다.

 

인커밍 포트 건너뛰기

아래 그림처럼 인커밍 포트를 제거한다면 계층사이이의 추상화를 줄일 수 있다. 느낌적으로 괜찮을 수 있지만 새로운 개바자가 코드를 파아할 때 내부 동작을 더 자세히 알아야 한다.

인커밍 어댑터가 있다면 인커밍 포트만을 호출 할 수 있어 어플리케이션 계층에 대한 모든 진입점을 정의하는 것이 의식적인 결정이 된다. 의도치 않은 서비스의 메서드를 실수로 호출하는 일이 절대 발생 할 수 없다.

 

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

어플리케이션 서비스를 건너 뛴다면 Persistence계층에서 바로 어플리케이션 인커밍포트에 연결된다.

간단한 CRUD 유스케이스에서는 통할지 모르겠지만 갈수록 복잡해 진다면 도메인 계층이 더 복잡해지고 흩어지며 유지보수하기 어려워진다. 단순 CRUD연산이 아니라 더 많은 일을 하게 된다면 서비스를 만드는 것이 더 좋다.