10장 - 아키텍처 경계 강제하기

일정 규모 이상의 모든 프로젝트에서는 시간이 지나면서 아키텍처가 서서히 무너지게 됩니다.

계층 간의 경계가 약화되고, 코드는 점점 더 테스트하기 어려워지게 됩니다.

 

해당 장에서는 아키텍처 내의 경계를 강제하는 방법과 아키텍처 붕괴에 맞서 싸우기 위해 취할 수 있는 전략을 살펴보고자 합니다.

 

경계와 의존성

경계를 강제한다는 것은 어떤 것을 의미할까요?

의존성 규칙에 따르면 경계는 항상 안쪽으로 향해야 합니다.

 

1. 접근제한자

public, private, protected에 대해서만 대부분 알고 있으며 default 제한자를 잘 모릅니다.

default 제한자는 패키지를 통해 클래스들을 응집적인 모듈로 만들어줍니다.

 

모듈 내의 클래스들은 서로 접근 가능하지만 패키지 바깥에서는 접근할 수 없습니다.

이제 모듈의 진입점으로 활용될 클래스들만 골라서 public으로 만들면 됩니다.

 

2. 컴파일 후 체크

public 제한자를 사용하면 의존성 방향이 잘못되어도 컴파일러는 허용합니다.

이를 방지하기 위해 컴파일된 후 런타임에 자동화된 테스트 과정을 통해 테스트합니다.

이를 도와주는 도구로 ArchUnit이 있습니다.

이제 패키지 사이의 의존성 방향이 올바른지 자동으로 체크할 수 있습니다.

 

3. 빌드 아티팩트

Maven, Gradle을 활용하여 하나의 JAR 파일로 패키징 합니다.

이를 통해 코드가 컴파일하기 전에 에러와 함께 빌드가 실패합니다.

개발자들은 더 이상 실수로 잘못된 의존성을 만들 수 없습니다.

 

 

결론

아키텍처를 잘 유지해나가고 싶다면 의존성이 올바른 방향을 가리키고 있는지 지속적으로 확인해야 합니다.

 

새로운 코드를 추가하거나 리팩터링할 때 패키지 구조를 항상 염두에 두어야 하며 package-private 가시성을 이용해 패키지 바깥에서 접근하면 안 되는 클래스에 대한 의존성을 피해야 합니다.

 

ArchUnit 같은 컴파일 후 체크 도구를 이용하거나 독립적인 빌드 모듈로 후출한다면 의존성 제어를 더 강화할 수 있습니다.