경계를 강제해야 하는 이유
- 일정 규모 이상의 프로젝트는 시간이 지나면 아키텍처는 무너지게된다. 이는 점점 테스트하기 어려워지고 새로운 기능을 구현하는 데 더 많은 시간이 든다
주요 내용
- 경계를 강제하는 방법
- 아키텍처 붕괴에 맞서 싸우기 위한 조치
경계를 강제한다 -> 의존성이 올바른 방향을 향하도록 강제한다는 것을 의미
의존성 관계
- 애플리케이션 -> 도메인
- 어댑터 -> 인커밍 포트 -> 서비스 -> 아웃고잉 포트를 -> 어댑터
- 설정계층 -> 어댑터, 서비스
자바에서 package-private 제한자는 왜 중요할까?
- 클래스들을 응집적인 모듈 로 만들어 준다
- 모듈은 모듈 내에 있는 클래스들은 서로 접근 가능하고 패키지 바깥에서는 접근할 수 없다
경계간 외부로 드러난 port 를 이용한다
- persistence 패키지에 있는 클래스들은 외부에서 접근할 필요가 없기 때문에 package-private 으로 만들 수 있다
- SendMoneyService 도 같은 이유로 package-private
package-private 단점
- 클래스가 특정 개수를 넘어가면 혼란스러워 지고, 이를 해결하기 위해 하위 패키지를 만들게 되면 다른 패키지로 취급되기 때문에 접근이 제한된다
코드가 컴파일된 후에 런타임에서 체크하는 방법
자바용 도구로는 ArchUnit (의존성 방향이 기대한 대로 잘 설정되 있는지 체크할 수 있는 API 제공)
단점
- 실패에 안전하지 않다 (오타, 리팩토링시 함께 유지보수) (개인의견) 제품의 테스트코드도 벅찬데 의존성을 위한 테스트코드는 짜지 않을것 같다
각 모듈의 빌드 스크립트에서 아키텍처에서 허용하는 의존성을 지정하는 방법
장점
- 모듈간 의존성을 더 잘 제어할 수 있다
- 순환 의존성을 허용하지 않는다
- 특정 모듈의 코드를 격리한 채로 변경할 수 있다 (모듈간 부리되어 있기 때문)
- 의존성이 스크립트에 명시적으로 선언되어 있다 (의식적인 행동)
단점
- 빌드 스크립트의 유지보수 비용 (빌드모듈 나누기 전에 아키텍처가 어느 정도 안정된 상태로 만든다)
- 모듈간 매핑을 더 많이 수행해야 한다 (그만큼 한 모듈에 대한 의존성이 줄어든다는 장점도 있다)
용어
- 빌드 아티팩트(artifact)
- (maven) or (gradle) 로 배포되는 결과물 (jar 파일이다)
- 구성요서 (group ID, artifact ID, version)로 artifact 를 구분하게 된다