TIL

10. 아키텍처 경계 강제하기

• 일정 규모 이상의 프로젝트에서는 시간이 지나면서 아키텍처가 서서히 무너진다.
• 아키텍처 내의 경계를 강제하는 방법과 아키텍처 붕괴에 대응해 취할 수 있는 몇 가지 조치가 있다.

경계와 의존성

• 육각형 아키텍처에선 가장 안쪽 계층에 도메인 계층이 존재하며 모든 의존성은 바깥에서 안으로 흐른다.
  • 애플리케이션 계층은 유스케이스를 구현하기 위해 도메인에 접근한다.
  • 어댑터는 인커밍 포트를 통해 서비스에 접근한다.
  • 서비스는 아웃고잉 포트를 통해 어댑터에 접근한다.
  • 설정 계층은 어댑터와 서비스 객체를 생성할 팩터리를 포함하며 의존성 주입 메커니즘을 제공한다.
• 이러한 의존성을 강제하여 의존성이 잘못된 방향으로 향하지 않도록 해야 한다.

접근 제한자

• package-private 제한자를 통해 패키지 내의 클래스들을 하나의 응집된 모듈로 만들 수 있다.
  • 모듈 내의 클래스들은 패키지 바깥에서는 접근할 수 없다.
  • 모듈의 진입점으로 활용될 클래스만 골라 public으로 만들면 된다.
• 육각형 아키텍처 패키지 구조
  • o 표시는 package-private 제한자, +는 public 제한자

    buckpal
    |---- account
         |---- adapter
              |---- in
                   |---- web
                        |---- o AccountController
              |---- out
                    |---- persistence
                         |---- o AccountPersistenceAdapter
                         |---- o SpringDataAccountRepository
         |---- domain
              |---- + Account
              |---- + Activity
         |---- application
              |----  o SendMoneyService
                   |---- port
                        |---- in
                             |---- + SendMoneyUseCase
                        |---- out
                             |---- + LoadAccountPort
                             |---- + UpdateAccountStatePort
  

  • 어댑터 패키지의 클래스들은 외부에서 접근할 필요가 없기에 package-private으로 만들 수 있다.
  • SendMoneyService도 인커밍 포트 인터페이스를 통해 호출되기에 바깥에서 접근할 필요가 없다.
• 이 방법을 사용하려면 애플리케이션 조립 시 클래스패스 스캐닝을 이용해야만 한다.
  • 컨피그 방식은 public 제한자를 이용해야 한다.
• 프로젝트 구조가 복잡해지고 하나의 패키지에 또 다른 하위 패키지를 추가하는 경우 하위 패키지는 다른 패키지로 취급되기에 하위 패키지 내부 클래스는 public으로 선언해야 한다.
  • 아키텍처 규칙이 깨질 수 있는 환경이 만들어진다.
  • public 제한자를 사용하면 컴파일 시점에서 의존성 규칙 위반 여부를 확인할 수 없다.

컴파일 후 체크

• 코드가 컴파일 된 후 런타임에 의존성 방향을 확인하는 방법이 있다.
• 지속적인 통합 빌드 환경에서 자동화된 테스트 과정에서 가장 잘 동작한다.

• ArchUnit 라이브러리를 통해 의존성 방향을 체크하는 테스트를 JUnit 환경에서 작성할 수 있다.

    class DependencyRuleTest {
      
        private static final String ROOT = "com.practice.cleanarichitecturehandson.buckpal.account.";
      
        @Test
        void domainLayerDoesNotDependOnApplicationLayer() {
            noClasses()
                    .that()
                    .resideInAnyPackage(ROOT + "domain..")
                    .should()
                    .dependOnClassesThat()
                    .resideInAnyPackage(ROOT + "application..")
                    .check(new ClassFileImporter()
                            .importPackages(ROOT + "..")
                    );
        }
    }
  

• 이러한 자동화된 테스트는 실패에 안전하지 않다. (fail-safe)
  • 패키지 이름에 오타를 내면 의존성 규칙 위반 사례를 발견하지 못한다.
  • 이를 방지하기 위해 클래스를 찾지 못했을 때 실패하는 테스트를 추가해야한다.
  • 그럼에도 리팩터링에 취약하다.

빌드 아티팩트

• 빌드 아티팩트는 빌드 프로세스의 결과물로 코드를 호출하고, 테스트하고, 하나의 JAR 파일로 패키징할 수 있다.
  • ex) Maven, Gradle
• 빌드 도구의 중요한 기능 중 하나는 의존성 해결이다.
  • 코드 베이스가 의존하고 있는 모든 아티팩트가 사용 가능한지 확인하고 사용 불가한 것이 있다면 에러와 함께 빌드가 실패한다.
• 빌드 도구를 활용해 모듈과 아키텍처의 계층 간 의존성을 강제할 수 있다.
• 각 계층에 대한 전용 코드 베이스와 빌드 아티팩트로 분리된 빌드 모듈을 만들어 아키텍처가 허용하는 의존성만 지정하는 것이다.

빌드 모듈 나누는 방법 예제

• 설정, 어댑터, 애플리케이션 계층의 빌드 아티팩트 (맨 왼쪽)
  • 가장 기본적인 3개의 모듈 빌드 방식
  • 설정 모듈은 나머지 2개 모듈 모두에 접근할 수 있고 어댑터 모듈은 애플리케이션 모듈에만 접근할 수 있다.
• 웹 어댑터, 영속성 어댑터를 격리한 빌드 아티팩트 (왼쪽에서 두 번째)
  • 이전 구조에선 웹 어댑터, 영속성 어댑터 간 의존성은 막지 않았는데 대부분의 경우 어댑터를 서로 격리시켜 유지하는 것이 좋다.
  • 애플리케이션을 다른 서드파티 API에 연결하는 다른 종류의 어댑터도 마찬가지인데 실제로 어댑터 간 의존성이 추가되어 외부 API와 관련된 사항이 다른 어댑터로 전파되는 것을 원치 않을 것이다.
• 애플리케이션 계층에서 포트(api 모듈)를 분리한 빌드 아티팩트 (오른쪽에서 두 번째)
  • 도메인 엔티티가 포트에서 전송 객체로 사용되지 않는 경우 (매핑하지 않기 전략) 의존성 역전 원칙을 통해 가능하다.
  • 어댑터 모듈과 애플리케이션 모듈은 API 모듈에 접근할 수 있지만 그 반대는 블가능하다.
• api 모듈을 인커밍 포트와 아웃고잉 포트 각각만 가지도록 한 빌드 아티팩트 (맨 오른쪽)
  • 특정 어댑터가 인커밍 어댑터인지 아웃고잉 어댑터인지를 명확하게 정의할 수 있다.
  • 애플리케이션 모듈을 서비스와 도메인 엔티티로 분리할 수도 있다.
  • 서비스, 도메인 분리를 통해 도메인이 서비스에 접근할 수 없어진다.

빌드 모듈로 아키텍처를 구분하는 방법의 장점

• 빌드 도구는 순환 의존성을 방지한다.
  • 순환 의존성은 변경이 잠재적으로 순환 고리에 포함되어 단일 책임 원칙을 위배하게 된다.
• 빌드 모듈은 다른 모듈을 고려하지 않고 특정 모듈의 코드를 격리한채로 변경할 수 있다.
  • 예를 들어 어댑터에서 컴파일 에러가 발생해도 애플리케이션 계층 테스트를 실행할 수 있다.
  • 심지어 각 모듈을 자체 코드 리포지토리에 넣어 다른 팀이 서로의 다른 모듈을 유지보수하게 할 수도 있다.
• 모듈 간 의존성이 빌드 스크립트에 분명히 선언되어 있기에 새로 의존성을 추가하는 일은 우연이 아닌 의식적인 행동이 된다.
• 하지만 빌드 스크립트를 유지보수하는 비용을 수반하기에 아키텍처가 어느 정도는 안정된 상태여야 여러 빌드 모듈로 나눌 수 있게 된다.