[클린 아키텍처 10] 아키텍처 경계 강화하기

경계와 의존성

'경계를 강제한다'는 것은 무엇인가

도메인 > 애플리케이션 > 어댑터 > 설정 

각 계층 사이의 경계를 유지하는 것. 계층 경계를 넘는 의존성은 항상 안쪽 방향으로 향하는 것!

 

접근 제한자

경제를 강제하는 가장 기본적인 도구 = 접근 제한자

 

package-private의 중요성 

- 자바 패키지를 통해 클래스들을 응집적인 '모듈'로 만들어줌 

- 패키지내 클래스들은 서로 접근 가능하지만, 패키지 바깥에서는 접근 불가

- 모듈의 진입점으로 활용된 클래스만 Public 설정 > 의존성 규칙 위반할 위험이 줄어듬

 

 

o이 package-private

- domain 패키지는 다른 계층에서 접근 가능 해야함

- application은 web 어댑터와 persitence 어댑터에서 접근 가능해야함

 

패키지내의 클래스가 특정 개수를 넘어가기 시작하면 

하나의 패키지에 너무 많은 클래스를 포함하는 것이 혼란스러워지게 된다. -> 하위 패키지 만드는 방법을 선호 

이렇게 되면 자바는 하위 패키지를 다른 패키지로 취급하기 때문에 하위 패키지의 p-p 멤버에 접근 불가 

결국 의존성 규칙이 깨질 수 있다.

 

컴파일 후 체크 

코드가 컴파일 된 후에 런타임에 체크한다.

지속적인 통합 빌드 환경에서 자동화된 테스트 과정에서 가장 잘 동작한다.

ArchUnit

계층간의 의존성 체크 가능

도메인 특화 언어 생성 가능

class DependencyRuleTests {
	@Test
	void validateRegistrationContextArchitecture() §
		HexagonalArchitecture.boundedContext("account") 
        	.withDomainLayer ("domain")
			.withAdaptersLayer ("adapter")
 			.incoming ("web") 
            .outgoing("persistence") 
            .and()
          .withApplicationLayer("application") 
           	.services ("service")
            .incomingPorts("port.in") 
            .outgoingPorts("port.out")
			.and() 
          .withConfiguration("configuration")
		  .check(new ClassFileImporter() 
          .importPackages("buckpal.."));

 

- check() : 몇가지 체크를 실쟁하고 패키지 의존성이 의존성 규칙에 따라 서정됐는지 검증

 

그러나 실패에 안전하진 않다.

패키지 이름에 오타를 내면...? 어떤 클래스도 찾지 못함! 

 

빌드 아티팩트

가장 있기있는 빌드 도구 -> 메이븐, 그레이들

빌드 도구의 주요한 기능중 하나는 의존성 해결! > 이를 활용해서 계층 간 의존성 강제 가능

 

모듈을 더 세분화할수록, 모듈 간 의존성을 더 잘 제어할 수 있게 된다.

더 작게 분리할수록 모듈 간에 매핑을 더 많이 수행해야 한다. 

 

장점

1) 빌드 도구는 순환 의존성을 싫어함 > 빌드 도구를 이용하면 모듈 간 순환 의존성이 없음을 확신 가능

 

2) 다른 모듈을 고려하지 않고 특정 모듈의 코드를 격리한 채로 변경할 수 있다. 

 

예를 들어 특정 어댑터에서 컴파일 에러가 생기는 애플리케이션 계층을 리팩터링하고 있다고 해보자.

어댑터와 애플리케이션 계층이 같은 빌드 모듈에 있다면 어댑터가 컴파일되지 않더라도 컴파일 계층을 모두 고쳐야 테스트 실행 가능 (IDE)

그러나 애프리케이션이 독립된 모듈이라면 어댑터에 신경 X > 테스트 마음대로 실행 가능

 

3) 모듈 간 의존성이 빌드 스크립트에 분명하게 선언돼 있기 때문에 새로 의존성을 추가하는 일은 의시적인 행동!

 

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

아키텍처 경계를 강제하고, 시간이 지나도 유지보수하기 좋으 코드를 만들 수 있다.