[클린 아키텍처 11] 의식적으로 지름길 사용하기

 

지름길을 방지하기 위해선 -> 먼저 지름길 자체를 파악해야 한다.

잠재적인 지름길에 대한 인식을 높이자!

 

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

깨진 창문 이론:

어떤 것이 멈춘 것처럼 보이고, 망가져 보이고, 혹은 관리되지 않는다고 여겨지면 인간의 뇌는 이를 더 멈추고, 망가뜨려도 된다고 생각하게 된다!

 

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

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

 

코드에 적용해보면?

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

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

 

깨끗한 상태로 시작할 책임

가능한 한 지름길을 거의 쓰지 않고 기술 부채를 지지 않은 채로 프로젝트를 깨끗하게 시작하자!

그러나 때로는 지름길을 취하는 것이 더 실용적일 때도 있다. 

- 프로젝트 전체로 봤을 때 그리 중요하지 않은 부분

- 프로토타이핑 작업 중

- 경제적인 이유 등등

이런 경우들은 잘 기록해 둘 것! (ex. 아키텍처 결정 기록 https://github.com/alphagov/govuk-aws/tree/main/docs/architecture/decisions)

 

육각형 아키텍처에서 고려해볼 수 있는 지름길은 뭐가 있는지 찾기

 

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

유스케이스마다 다른 입출력 모델을 가져야한다.

 

 

 

sendmoneyusecase와 revokeacivityusecase가 결합된다.

sendmoneycommand가 변경되면 두 유스케이스보두 영향을 받음

 

그러나 유스케이스들이 기능적으로 묶여있으면 공유 ok 

특정 세부사항을 변경할 경우 실제로 두 유스케이스 모두에 영향을 주고 싶은 경우!

 

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

 

 

Account 엔티티에 존재하지 않는 정보를 유스케이스가 필요로 한다면?

다른 도메인이나 다른 바운디드 컨텍스트에 저장돼야 함. 그러나 이미 유스케이스 인터페이스에서 AccountEntity를 사용하고 있기 때문에 새로운 필드를 추가하고 싶은 마음이 든다!

 

간단한 생성은 괜찮지만.. 더 복잡한 도메인 로직을 구현해야 한다면?

유스케이스 인터페이스에 대한 전용 입출력 모델을 만들어야 한다.

우스케이스 변경 > 도메인 엔티티에 영향을 끼치고 싶지 않다면!

 

인커밍 포트 건너뛰기

인커밍 포트없이 컨트롤러가 바로 서비스를 바라본다면?

특정 유스케이스를 구현하기 위해 어떤 서비스 메서드를 호출애햐 할지 알아내기 위해 애플리케이션의 내부 동작에 대해 더 잘 알아야 한다. 전용 인커밍 포트를 유지하면 한눈에 진입점 식별 가능 

 

그리고 인커밍 포트는 아키텍처를 강제할 수 있다.

인커밍 어댑터가 서비스가 아닌 포트만 호출하게끔 제어 가능 

 

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

애플리케이션 계층을 통째로 건너뛰고 싶은 경우?

 

PersistenceAdapter 클래스는 직접 인커밍 포트를 구현해서 애플리케이션 서비스를 대체한다.

간단한 CRUD 유스케이스에서는 보통 애플리케이션 서비스가 도메인 로직 없이 생성,업데이트, 삭제 요청을 그대로 영속성 어댑터에 전달.

 

하지만 이 방법은 인커밍 어댑터와 아웃고잉 어댑터 사이에 모델을 공유해야 한다.

그리고 유스케이스가 없어진다. CRUD 유스케이스가 점점 복잡해지면 도메인 로직을 그대로 아웃고잉 어댑터에 추가하고 싶은 생각이 들 것이다.

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

 

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

단순 CRUD 상태에서 더이상 벗어나지 않는 경우 > 지름길 유지하는게 경제적

그러나 그게 아니라면? -> CRUD에서 벗어나는 시점이 언제인지에 대해 합의하자!