10 아키텍처 경계 강제하기

경계와 의존성

• 경계를 강제: 의존성이 올바른 방향을 향하도록 강제

접근 제한자

• package-private 제한자는 자바 패키지를 통해 클래스들을 응집적인 ‘모듈’로 만들어준다. 이 모듈 내에 있는 클래스들은 서로 접근 가능하지만, 패키지 바깥에서는 접근할 수 없다. 그럼 모듈의 진입점으로 활용될 클래스들만 골라서 public으로 만들면 된다.
• 이 방법은 클래스패스 스캐닝을 이용해야만 한다. 다른 방법은 객체 인스턴스를 직접 생성해야 하기 때문에 public 제한자를 이용해야 한다.
  • 모듈이 커지면 효과가 떨어짐
  • 자바는 하위 패키지를 다른 패키지로 취급하기 때문에 하위 패키지의 package-private 멤버에 접근할 수 없게 된다. 그래서 하위 패키지의 멤버는 public으로 만들어서 노출시켜야 하기 때문에 의존성 규칙이 깨질 수 있게 된다.

컴파일 후 체크

• 컴파일 후 체크(post-compile check): 코드가 컴파일 된 후에 런타임에 체크한다.

빌드 아티팩트

• 각 모듈 혹은 계층에 대해 전용 코드베이스와 빌드 아티팩터로 분리된 빌드 모듈(JAR 파일)을 만들 수 있다.
  • 각 모듈의 빌드 스크립트에서는 아키텍처에서 허용하는 의존성만 지정한다.
  • 클래스들이 클래스패스에 존재하지 않아 컴파일 에러가 발생하므로 잘못된 의존성을 만들 수 없다.
• 장점
  • 순환 의존성을 허용하지 않음
  • 다른 모듈을 고려하지 않고 특정 모듈의 코드를 격리한 채로 변경 가능
  • 의식적으로 새로운 의존성을 추가하게 된다.
• 단점
  • 빌드 스크립트 유지보수 비용

11 의식적으로 지름길 사용하기

깨진 유리창

• 한 번 망가지면, 그 다음은 더 쉽고 빠르게 망가진다.
• 코드도 그렇다.
  • 품질이 떨어진 코드에서 작업할 때 더 낮은 품질의 코드를 추가하기 쉽다.
  • 코딩 규칙을 많이 어긴 코드에서 작업할 때 또 다른 규칙을 어기기도 쉽다.
  • 지름길을 많이 사용한 코드에서 작업할 때 또 다른 지름길을 추가하기도 쉽다.

깨끗한 상태로 시작할 책임

• 의도적인 지름길이 있을 수 있으나, 일반적으로는 깨진 창문을 만들지 말아야 한다.

유스케이스 간 모델 공유하기

• 유스케이스 간 입출력 모델을 공유하는 것은 유스케이스들이 기능적으로 묶여 있을 때 유효하다.
  • 특정 세부사항을 변경할 경우 실제로 두 유스케이스 모두에 영향을 주고 싶은 경우다.
• 서로 미치는 영향이 없어야 한다면, 공유하지 않고 분리해야 한다.

도메인 엔티티를 입출력 모델로 사용하기

• 유스케이스 변경이 도메인 엔티티까지 전파되길 바라지 않는다면 분리하는게 맞다.
  • 이 지름길은 많은 유스케이스가 시간이 지남에 따라 도메인 로직 괴물이 되어간다는 점에서 위험하다.

인커밍 포트 건너뛰기

• 인커밍 포트는 애플리케이션 중심에 접근하는 진입점을 정의한다. 이 추상화 계층을 제거하면 특정 유스케이스를 구현하기 위해 어떤 서비스 도메인을 호출해야 할지 알아내기 위해 애플리케이션 내부 동작에 대해 더 잘 알아야 한다.
• 인커밍 포트는 아키텍처를 쉽게 강제할 수 있다. 즉, 애플리케이션 계층에 대한 모든 진입점을 정의하는 것이 아주 의식적인 결정이 된다. 실수로 호출하는 일이 절대 발생할 수 없다.

애플리케이션 서비스 건너뛰기

• 인커밍 어댑터와 아웃고잉 어댑터 사이 모델을 공유해야 한다. 결국 도메인 모델을 입력 모델로 사용하는 케이스가 된다. 나아가 애플리케이션 코어에 유스케이스라고 할 만한 것이 없어진다.
  • 도메인 로직이 흩어져서 도메인 로직을 찾거나 유지보수하기 어려워진다.

12 아키텍처 스타일 결정하기

• 언제 어떤 아키텍처를 사용해야 할까?

도메인이 왕이다

• 외부의 영향을 받지 않고 도메인 코드를 자유롭게 발전시킬 수 있다는 것은 육각형 아키텍처 스타일이 내세우는 가장 중요한 가치다.
  • DDD랑 잘 어울리는 이유
• 첫 번째 지표로, 만약 도메인 코드가 애플리케이션에서 가장 중요한 것이 아니라면 이 아키텍처 스타일은 필요하지 않을 것이다.

경험이 여왕이다

• 우리가 과거에 했던 일에 편안함을 느끼는데 무언가를 바꿔야 할 이유가 있을까?
• 아키텍처 스타일에 대해서 괜찮은 결정을 내리는 유일한 방법은 다른 아키텍처 스타일을 경험해 보는 것이다.
  • 확신이 없다면, 지금 만들고 있는 애플리케이션의 작은 모듈에 먼저 시도해 볼 것
  • 그러면 이 경험이 다음 아키텍처 결정을 이끌어 줄 것이다.

그때그때 다르다

• 어떤 소프트웨어를 만드는지, 도메인 코드의 역할이 어떤지, 팀의 경험이 어떤지, 최종적으로 내린 결정이 마음에 드는지 모두 그때그때 다르다.