https://d2.naver.com/helloworld/9222129
아키텍처(architecture)는 정의에 따르면 컴퓨터 공학에서 컴퓨터 시스템의 기능, 조직, 구현에 대한 법칙과 방법을 의미합니다.
최근에는 GitHub 저장소에 README.md 파일과 더불어 ARCHITECTURE.md 파일을 추가해 아키텍처 설명서를 제공하자는 주장도 나오고 있습니다. 개발자들은 프로젝트 아키텍처에 맞게 개발해야 하는데 아키텍처에 익숙하지 않은 오픈소스 참여자나 새로 유입된 인원이라면 아키텍처 파악에만 많은 시간이 소요되기 때문에 아키텍처를 쉽게 파악할 수 있게 설명서를 적어 놓아야 한다는 주장입니다.
이러한 별도의 설명서가 없어도 서술적인 메서드명으로 한눈에 아키텍처 구조를 알 수 있고 반대로 아키텍처의 규칙도 쉽게 정의할 수 있으며 더불어 검사까지 가능하게 해주는 것이 바로 ArchUnit입니다. 이 글에서는 ArchUnit의 사용법을 간단히 설명하고, 네이버에서 ArchUnit을 사용해 아키텍처를 검사한 사례를 소개합니다.
ArchUnit은 다음과 같은 기능을 제공한다.
패키지와 클래스의 의존 관계 확인
프로젝트 수준에서 패키지의 의존 관계를 확인하거나 패키지 수준에서 클래스의 의존 관계를 확인할 수 있다. 또한 클래스와 패키지의 관계도 확인할 수 있어, 클래스가 잘못된 패키지를 의존하고 있는 경우 쉽게 찾아낼 수 있다.
상속 관계, 순환 참조 검사
규칙(rule)을 정의해 상속이 일어나면 안 되는 경우나 잘못 상속된 경우, 상속이 복잡하게 발생해 순환 참조가 일어나는 경우를 검사할 수 있다.
레이어 아키텍처 검사
클래스명 또는 패키지명을 사용해 손쉽게 레이어를 정의하고 레이어의 관계를 정의하고 검사할 수 있으며, 코멘트나 애너테이션, 프로퍼티까지도 검사할 수 있다.
직접 규칙을 정의해 코딩 컨벤션 준수 여부를 검사
팀마다 스타일대로 규칙을 정하고 준수 여부를 검사해 코딩 컨벤션을 지켜나가는 데 도움을 줄 수 있다.
ArchUnit 테스트가 진행되기 위해서는 먼저 규칙을 설정해야 한다. 예를 들어 "지원 모듈은 비즈니스 모듈에 접근할 수 없다"라는 규칙을 정했다면, 다음과 같이 간단하게 설정할 수 있다.
// 지원 모듈은 support 패키지에, 비즈니스 모듈은 charge 패키지에 있을 경우
ArchRule rule = noClasses().that().resideInPackage("..support..")
.should().accessClassesThat().resideInPackage("..charge..");
이 규칙을 정해놓은 도메인에서 테스트를 진행해 통과한다면 견고한 아키텍처를 유지할 수 있다
또한 테스트 코드를 유지하고 프로젝트를 진행하다가, PR 빌드나 프로젝트 빌드 시 오류가 발생하면 프로젝트 아키텍처 규칙 위반 여부를 검사할 수도 있다.
미리 아키텍처 규칙을 만들어 둔다면, 프로젝트 진행 중 아키텍처에 맞는 코드를 작성 중인지 빠르고 쉽게 검사하며 프로젝트를 완성해 나갈 수 있다.
ArchUnit 사용법은 크게 선언형 검사, 명령형 검사, AssertJ 연동 방식의 세 가지로 나눌 수 있다.