만들면서 배우는 클린 아키텍처 - 11 정리

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

잠재적인 지름길에 대한 인식을 높이고 그 영향에 대해 이야기한다.

이 정보만 있어도 우발적으로 사용되는 지름길을 인식하고 수정할 수 있다.

정당한 지름길이라면 지름길의 효과를 의식적으로 택할 수도 있다.

어떤때는 (의식적으로)지름길을 먼저 취하고 나중에 고치는 것이(혹은 아예 고치지 않더라도) 실제로 더 경제적일 수도 있다.

 

---

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

깨진 창문(유리창) 이론 : 깨진 유리창 하나를 방치해 두면, 그 지점을 중심으로 범죄가 확산되기 시작한다는 이론으로, 사소한 무질서를 방치하면 큰 문제로 이어질 가능성이 높다는 의미를 담고 있다.
출처 - https://ko.wikipedia.org/wiki/%EA%B9%A8%EC%A7%84_%EC%9C%A0%EB%A6%AC%EC%B0%BD_%EC%9D%B4%EB%A1%A0

코드 작업에 적용되는 깨진 창문(유리창) 이론

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

이 모든 것을 고려하면 이른바 '레거시' 라고 불리는 많은 코드의 품질이 시간이 가면서 심하게 낮아졌다는 게 그리 놀라운 일은 아니다.

 

---

깨끗한 상태로 시작할 책임

깨진 창문을 막는 것이 소프트웨어 개발자들의 아주 막대한 책임이다.

프로젝트를 인계받을 때 이 코드가(깨진 창문 같은 코드) 연관성이 전혀 없는 레거시이기 때문에 깨진 창문을 만들어 내기가 더 쉽다.

프로토타이핑이나 경제적인 이유가 있어서 지름길을 취하는 것이 더 실용적일 때도 있다.

 

의도적인 지름길에 대해서는 잘 기록해둬야 한다.

마이클 나이가드가 제안한 아키텍처 결정 기록의 형태도 괜찮다.

지름길이 의도적으로 추가된 사실을 알기 때문에 깨진 창문 이론의 영향을 더 줄일 수 있다.

 

---

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

유스케이스 간 모델 공유로 인한 영향은 SendMoneyUseCase와 RevokeActivityUseCase가 결합된다는 것이다.

단일 책임 원칙에서 이야기하는 '변경할 이유'를 공유하게 된다.

 

유스케이스 간 입출력 모델을 공유하는 것은 유스케이스들이 기능적으로 묶여 있을 때 유효하다.

즉, 특정 요구사항을 공유할ㄷ 때 괜찮다는 의미다.

특정 세부사항을 변경할 경우 두 유스케이스 모두에게 영향을 주고 싶은 것이다.

 

두 유스케이스가 서로 영향이 없이 독립적으로 진화해야한다면, 입출력 모델 공유는 지름길이 된다.

독립적으로 진화해야한다면 코드가 같더라도 복사해서 사용해야한다.

 

비슷한 입출력 모델을 사용해서 공유하더라도 독립적으로 진화를 한다면, 그때는 입출력 모델을 분리해아할 때이다.

 

---

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

인커밍 포트는 도메인 엔티티에 의존성을 가지고 있다. Account 엔티티는 변경할 또 다른 이유가 생겼다.

 

Account 엔티티에는 존재하지 않는 정보를 유스케이스가 필요로 한다면, Account 엔티티에 저장돼 있어야 하는 것이 아니라 다른 도메인이나 다른 바운디드 컨텍스트에 저장돼야 한다.

그럼에도 불구하고 유스케이스 인터페이스에 사용할 필드를 Account 엔티티에 추가하고 싶다는 생각이 든다.

 

간단한 생성이나 업데이트 유스케이스에서는 유스케이스 인터페이스에 도메인 엔티티가 데이터베이스에 저장하기 때문에 괜찮을지 모른다.

 

하지만 유스케이스가 단순히 데이터베이스의 필드 몇 개를 업데이트하는 수준이 아니라 복잡하다면, 유스케이스 인터페이스에 대한 전용 입출력 모델을 만들어야 한다.

 

이 지름길이 위험한 이유는 유스케이스가 시간이 지나면서 도메인 로직 괴물이 되어갑니다.

코드량이 늘어간다는 것을 의미하는걸까?
코드를 분리해서 유스케이스 분리를 한다면 괴물까지 갈까..?

처음엔 간단했지만 시간이 지나며 복잡도가 높여가는 애자일 환경에서 특히 그렇다.

도메인 모델을 사용하다가 입력 모델로 교체해야 하는 시점을 잘 파악해야한다.

 

---

인커밍 포트 건너뛰기

인커밍 어댑터가 인커밍 포트 없이 애플리케이션 서비스에 직접 접근하도록 할 수 있다.

인커밍 포트를 제거함으로써 인커밍 어댑터와 애플리케이션 계층 사이의 추상화 계층을 줄였다.

 

인커밍 포트는 애플리케이션 중심에 접근하는 진입점을 정의한다.

인커밍 포트를 유지하면 한눈에 진입점을 식별할 수 있다.

새로운 개발자가 코드를 파악할 때 특히 더 도움된다.

아키텍처를 쉽게 강제하기 위해서 인커밍 포트를 유지해야한다.

인커밍 어댑터에서 호출할 의도가 없던 서비스 메서드를 실수로 호출하는 일이 절대 발생할 수 없다.

 

규모가 작다면 하나의 인커밍 어댑터나 없어도 서비스 구조를 파악하기 쉽지만 시간이 지나서 규모가 커진다면 인커밍 어댑터가 하나이거나 없다면 서비스 구조를 쉽게 파악하긴 어려울 것 같다.

 

---

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

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

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

 

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

이는 결국 도메인 로직이 흩어져서 도메인 로직을 찾거나 유지보수하기하기 어려워진다.

 

보일러플레이트 코드를 방지하기 위해 간단한 CRUD 케이스에서는 애플리케이션 서비스를 건너뛰기로 결정할 수도 있다.

CRUD보다 더 많은 일을 한다면 애플리케이션 서비스를 만든다는 명확한 가이드라인을 팀에 정해둬야한다.

 

---

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

간단한 CRUD 유스케이스에 대해서는 전체 아키텍처를 구현하는 것이 지나치게 느껴지기 때문에 지름길의 유혹을 느낄 수 있다.

처음에 작게 시작하기 때문에, CRUD를 벗어난 시점이 언제인지 팀이 합의하는 것이 매우 중요하다.

합의가 되어야 장기적으로 더 유지보수 하기 좋은 아키텍처로 대체할 수 있다.

 

단순 CRUD에서 더 이상 벗어나지 않는다면 지름길을 계속 유지하는 게 더 경제적이다.

 

만약 지름길을 선택한다면 그에 대한 기록을 남겨서 나중에 이 결정에 대해 다시 평가할 수 있게 하자.