34장 - 빠져 있는 장

계층 기반 패키지

전형적인 계층형 아키텍처에는 웹, 업무 규칙, 영속성 코드를 위한 계층이 하나씩 존재합니다.

OrderController(Spring MVC)

OrdersService(인터페이스)

OrderServiceImpl(구현체)

OrdersRepository(인터페이스)

JdbcOrderRepository(구현체)

 

기능 기반 패키지

서로 연관된 기능, 도메인 개념, 또는 Aggregate Root에 기반하여 수직의 얇은 조각으로 코드를 나누는 방식입니다.

Aggregate Root란 에릭 에반스의 도메인 주도 설계에 나온 개념으로 데이터 변경의 단위로 다루는 연관 객체의 묶음입니다.

 

orders라는 패키지를 두고 Controller, Service, Repository를 모두 묶어둡니다.

이제 주문 조회하기 유스케이스가 변경될 경우에 orders패키지로 이동해서 수정하면 됩니다.

 

포트와 어댑터

코드 베이스는 내부(도메인)과 외부(인프라로) 구성됨을 흔히 볼 수 있습니다.
어떻게 보면 계층 기반 패키지와 유사한 모습이지만 업무/도메인에 초점을 둔 코드가 프레임워크나 데이터베이스 같은 기술적인 세부 구현과 독립적으로 분리된 아키텍처를 만들어냅니다.

 

OrderRepoisotry가 Orders라는 간단한 이름으로 바뀌었습니다.

도메인에 대해 논의할 때 우리는 '주문'에 대해 말하는 것이지 '주문 리포지터리'에 대해 말하지 않습니다.

 

컴포넌트 기반 패키지

계층형 아키텍처를 사용하더라도 Controller에서 바로 Repository를 사용할 수 있습니다.

의존성 화살표는 여전히 아래를 향하지만 몇몇 유스케이스는 Service를 사용하지 않습니다.

이런 조직화는 계층을 건너뛰는 일이 허용되기 때문에 완화된 계층형 아키텍처라고 부릅니다.

 

적은 수의 팀만이 빌드 시 정적 분석 도그를 사용해서 아키텍처적인 위반이 없는지 검사하여 강제합니다.

 

만약 컴포넌트 기반 패키지를 도입하게 된다면 큰 단위의 단일 컴포넌트와 관련된 책임을 하나의 자바 패키지로 묶는 데 주안점을 둡니다.

 

서비스 중심적인 시각으로 소프트웨어 시스템을 바라보며 마이크로서비스 아키텍처가 가진 시각과도 동일합니다.

 

업무 로직과 영송성 관련 코드를 하나로 묶어 컴포넌트라고 부릅니다.

컴포넌트는 멋지고 깔끔한 인터페이스로 감싸진 연관된 기능들의 묶음으로, 애플리케이션과 같은 실행 환경 내부에 존재합니다.

 

컴포넌트 기반 패키지의 접근법의 주된 이점은 주문과 관련된 무엇가를 코딩해야 할 때 오직 한 곳, 즉 OrdersComponent만 둘러보면 된다는 점입니다.

 

이 컴포넌트 내부에서 관심사의 분리는 여전히 유효하며, 업무 로직은 데이터 영속성과 분리되어 있습니다.

 

구현 세부사항엔 항상 문제가 있다

보통 개발자들이 public 키워드를 아무런 고민없이 사용합니다.

이는 프로그래밍 언어에서 제공하는 캡슐화 관련 이점을 활용하지 않겠다는 뜻입니다.

또한 당신이 지향하는 아키텍처 스타일을 위반하게 만듭니다.

 

만약 모든 타입을 public으로 표기한다면 우리가 실제로 갖게 되는 수평적 계층형 아키텍처를 표현하는 네 가지 방식에 지나지 않습니다.

 

접근 지시자를 적절히 사용하면, 타입을 패키지로 배치하는 방식에 따라 각 타입에 접근할 수 있는 정도가 실제로 크게 달라질 수 있습니다.

 

포트와 어앱터의 경우 public으로 지정하며 구현 클래스 패키지는 protected로 지정하여 접근에 제한을 두는 게 좋습니다.

 

 

다른 결합 분리 모드

접근 제어자 이외에도 소스 코드 의존성을 분리하는 방법은 존재합니다.

예를 들어 자바에는 OSGi 같은 모듈 프레임워크나 자바9에서 제공하는 새로운 모듈 시스템이 있습니다.

 

다른 선택지로는 소스 코드 수준에서 의존성을 분리하는 방법도 있습니다.

 

모듈이나 프로젝트가 서로 분리되도록 구성하여 해결할 수 있습니다.

 

결론: 빠져 있는 조언

최적의 설계를 꾀했더라도, 구현 전략에 얽힌 복잡함을 고려하지 않으면 설계가 순식간에 망가질 수 있습니다.

런타임과 컴파일타임에 어떤 결합 분리 모드를 적용할지 고민해야 합니다.

가등하다면 선택지를 항상 열어두어야 합니다.

 

선택된 아키텍처 스타일을 강제하는 데 컴파일러의 도움을 받을 수 있는지 고민하며, 데이터 모델과 같은 다른 영역에 결합되지 않도록 주의해야 합니다.

구현 세부사항에는 항상 문제가 있는 법입니다.