- 의식적으로 지름길 사용하기
이번 장의 목표는 잠재적인 지름길에 대한 인식을 높이고 그 영향에 대해 이야기하는 것이다.
왜 지름길은 깨진 창문 같을까?
깨진 창문 이론을 나만의 표현으로 바꿔보면 다음과 같다.
어떤 것이 멈춘 것처럼 보이고, 망가져 보이고, [부정적인 형용사를 넣어보자], 혹은 관리되지 않는다고 여겨지는 인간의 뇌는 이를 더 멈추고, 망가뜨리고, [부정적인 형용사를 넣어보자] 해도 된다고 생각하게 된다.
코드 작업에 적용될 때의 의미는 다음과 같다.
- 품질이 떨어진 코드에서 작업할 때 더 낮은 품질의 코드를 추가하기가 쉽다.
- 코딩 규칙을 많이 어긴 코드에서 작업할 때 또 다른 규칙을 어기기도 쉽다.
- 지름길을 많이 사용한 코드에서 작업할 때 또 다른 지름길을 추가하기도 쉽다.
이 모든 것을 고려하면 이른바 '레거시'라고 불리는 많은 코드의 품질이 시간이 가면서 심하게 낮아졌다는 게 그리 놀라운 일은 아니다.
깨끗한 상태로 시작할 책임
때로는 지름길을 취하는 것이 더 실용적일 때도 있다. 작업 중인 부분이 프로젝트 전체로 봤을 때 그리 중요하지 않은 부분이거나, 프로토타이핑 작업 중이거나, 경제적인 이유가 있을 수도 있다.
이러한 의도적인 지름길에 대해서는 세심하게 잘 기록해둬야 한다. 마이클 나이가드(Michael Nygard)가 제안한 아키텍처 결정 기록(Architecture Decision Records, ARDs)의 형태도 괜찮다. 우리는 미래의 우리 혹은 프로젝트를 인계받는 이들에게 빚을 지고 있는 것이다. 만약 팀원 모두가 이 문서에 대해 인지하고 있다면 지름길이 합리적인 이유에 대해 의도적으로 추가됐다는 사실을 알기 때문에 깨진 창문 이론의 영향을 더 줄일 수 있을 것이다.
이어지는 절에서는 육각형 아키텍처에서 고려해볼 수 있는 지름길들을 몇 가지 이야기해보려고 한다.
유스케이스 간 모델 공유하기
4장에서는 유스케이스마다 다른 입출력 모델을 가져야 한다고 이야기한 바 있다. 즉, 입력 파라미터의 타입과 반환값의 타입이 달라야 한다는 뜻이다.
그림 11.1은 두 개의 유스케이스가 같은 입력 모델을 공유하는 예를 보여준다.
공유로 인해 SendMoneyCommand와 RevokeActivityUseCase가 결합된다는 것이다. 공유하고 있는 SendMoneyCommand 클래스가 변경되면 두 유스케이스 모두 영향을 받는다. 단일 책임 원칙에서 이야기하는 '변경할 이유'를 공유하는 것이다. 출력 모델을 공유하는 경우에도 마찬가지다.
유스케이스 간 입출력 모델을 공유하는 것은 유스케이들이 기능적으로 묶여 있을 때 유효하다. 즉, 특정 요구사항을 공유할 때 괜찮다는 의미다. 이 경우 특정 세부사항을 변경할 경우 실제로 두 유스케이스 모두에 영향을 주고 싶은 것이다.
두 유스케이스가 서로 간에 미치는 영향 없이 독립적으로 진화해야 한다면 입출력 모델을 공유하는 방식은 지름길이 된다. 만약 독립적으로 진화해야 한다면 처음에는 똑같은 입출력 클래스를 복사해야 하더라도 일단 분리해서 시작해야 한다.
그러므로 비슷한 개념의 유스케이스 여러 개를 만든 다음 유스케이스를 독립적으로 진화할 필요가 있는지 주기적으로 질문해야 한다. 대답이 "예"가 되는 그때가 바로 입출력 모델을 분리할 시점이다.
도메인 엔티티를 입출력 모델로 사용하기
도메인 엔티티인 Account와 인커밍 포트인 SendMoneyUseCase가 있으면 엔티티를 인커밍 포트의 입출력 모델로 사용하고 싶다는 생각이 들지도 모른다. 그림 11.2를 보자.
인커밍 포트는 도메인 엔티티에 의존성을 가지고 있다. 그 결과, Account 엔티티는 변경할 또 다른 이유가 생겼다.
하지만, Account 엔티티는 인커밍 포트인 SendMoneyUseCase에 의존성이 없으니(의존성의 방향이 반대) 인커밍 포트가 어떻게 엔티티를 변경할 이유가 된다는 뜻일까?
현재 Account 엔티티에는 존재하지 않는 정보를 유스케이스가 필요로 한다고 생각해보자. 이 정보는 최종적으로 Account 엔티티에 저장돼 있어야 하는 것이 아니라 다른 도메인이나 다른 바운디드 컨텍스트에 저장돼야 한다. 그럼에도 불구하고 이미 유스케이스 인터페이스에서 사용할 수 있기 때문에 Account 엔티티에 새로운 필드를 추가하고 싶다는 생각이 든다.
간단한 생성이나 업데이트 유스케이스에서는 유스케이스 인터페이스에 도메인 엔티티가 있는 것이 괜찮을지도 모른다. 데이터베이스에 저장해야 하는 바로 그 상태 정보가 엔티티에 있기 때문이다.
하지만 유스케이스가 단순히 데이터베이스의 필드 몇 개를 업데이트하는 수준이 아니라 더 복잡한 도메인 로직을 구현해야 한다면(도메인 로직의 일부를 풍분한 도메인 엔티티로 위임할 수도 있으니), 유스케이스 인터페이스에 대한 전용 입출력 모델을 만들어야 한다. 왜냐하면 유스케이스의 변경이 도메인 엔티티까지 전파되길 바라진 않을 것이기 때문이다.
이 지름길이 위험한 이유는 많은 유스케이스가 간단한 생성 또는 업데이트 유스케이스로 시작해서 시간이 지나면서 복잡한 도메인 로직 괴물이 되어간다는 사실 때문이다. 그러므로 도메인 엔티티를 입력 모델로 사용했더라도 도메인 모델로부터 독립적인 전용 입력 모델로 교체해야 하는 시점을 잘 파악해야 한다.
인커밍 포트 건너뛰기
아웃고잉 포트는 애플리케이션 계층과 아웃고잉 어댑터 사이의 의존성을 역전시키기 위한 (의존성이 안쪽으로 향하게 하는) 필수 요소인 반면 인커밍 포트는 의존성 역전이 필수적인 요소는 아니다. 인커밍 어댑터가 인커밍 포트 없이 애플리케이션에 직접 접근하도록 할 수 있다. 그림 11.3을 보자.
인커밍 포트는 애플리케이션 중심에 접근하는 진입점을 정의한다. 이를 제거하면 특정 유스케이스를 구현하기 위해 어떤 서비스 메서드를 호출해야 할지 알아내기 위해 내부 동작에 대해 더 잘 알아야 한다. 전용 인커밍 포트를 유지하면 한눈에 진입점을 식별할 수 있다. 전용 인커밍 포트를 유지하면 한눈에 진입점을 식벽할 수 있다.
인커밍 포트를 유지하는 또 다른 이유는 아키텍처를 쉽게 강제할 수 있기 때문이다.
애플리케이션 서비스 건너뛰기
어떤 유스케이스는 애플리케이션 계층을 통째로 건너 뛰고 싶을 수도 있다. 그림 11.4를 보자.
그림에서 아웃고잉 어댑터에 있는 AccountPersistenceAdapter 클래스는 직접 인커밍 포트를 구현해서 일반적으로 인커밍 포트를 구현하는 애플리케이션 서비스를 대체한다.
간단한 CRUD 유스케이스에서는 보통 애플리케이션 서비스가 도메인 로직 없이 생성, 업데이트, 삭제 요청을 그대로 영속성 어댑터에 전달하기 때문에 정말 구미가 당기는 방법이다. 그대로 전달하는 대신 영속성 어댑터가 직접 유스케이스를 구현하게 할 수 있다.
하지만 이 방법은 인커밍 어댑터와 아웃고잉 어댑터 사이에 모델을 공유해야 한다. 이 경우엔 Account 도메인 엔티티(도메인 모델)를 입력 모델로 사용하는 케이스가 되는 것이다.
나아가 애플리케이션 코어에 유스케이스라고 할 만한 것이 없어진다. 만약 시간이 지남에 따라 CRUD 유스케이스가 점점 복잡해지면 도메인 로직을 그대로 아웃고잉 어댑터에 추가하고 싶은 생각이 들 것이다. 이미 유스케이스가 어댑터에 있으니 말이다. 이렇게 되면 도메인 로직이 흩어져서 도메인 로직을 찾거나 유지보수하기가 어려워진다.
유지보수 가능한 소프트웨어를 만드는 데 어떻게 도움이 될까?
경제적인 관점에서 지름길이 합리적일 때도 있다. 이번 장에서는 지름길을 사용할지 여부를 결정하는 데 도움이 되도록 지름길을 사용한 결과에 대한 식견을 제공했다.
어떤 경우든 아키텍처에 대해, 그리고 왜 특정 지름길을 선택했는가에 대한 기록을 남겨서 나중에 우리 자신 또는 프로젝트를 인계받는 이들이 이 결저에 대해 다시 평가할 수 있게 하자.
