빠져 있는 장
34. 빠져 있는 장
프레임워크는 아키텍처가 될 수 없다.
계층 기반 패키지
수평 계층형 아키텍처
처음 시작하기에 적합
Controller, Service, Repository
엄청난 복잡합을 겪지 않고도 무언가를 작동시켜 주는 아주 빠른 방법
소프트웨어가 커지고 복잡해지기 시작하면, 더 잘게 모듈화를 해야 할지 고민하게 됨
업무 도메인에 대해 아무것도 말해주지 않는다는 문제도 있음
기능 기반 패키지
서로 연관된 기능, 도메인 개념에 기반하여 수직의 얇은 조각으로 코드를 나누는 방식
Controller, Service, Repository 가 하나의 패키지
변경하기 쉬움
상위 수준 구조가 업무 도메인에 대해 알려줌
포트와 어댑터
업무/도메인에 초점을 둔 코드가 프레임워크가 데이터베이스 같은 기술적인 세부 구현과 독립적이며 분리된 아키텍처가 필요
그런 코드베이스는 내부(도메인)와 외부(인프라)로 구성
모든 의존성이 ‘내부’로 향함
컴포넌트 기반 패키지
계층형 아키텍처의 목적은 기능이 같은 코드끼리 서로 분리하는 것
엄격한 계층형 아키텍처에서는 의존성 화살표는 항상 아래를 향해야 하며, 각 계층은 반드시 바로 아래 계층에만 의존해야 한다.
하지만 컨트롤러에서 레포지토리로 직접 접근하는 경우가 생김
그래서 지침이 필요
컴포넌트 기반 패키지는 큰 단위의 단일 컴포넌트와 관련된 모든 책임을 하나의 자바 패키지로 묶는 데 주안점을 둔다.
이 접근법은 서비스 중심적인 시각으로 소프트웨어 시스템을 바라보며, 마이크로서비스 아키텍처가 가진 시각과도 동일하다.
이 접근법에서는 ‘업무 로직’과 영속성 관련 코드를 하나로 묶는 데, 이 묶음을 ‘컴포넌트’
컴포넌트는 배포 단위다. 컴포넌트는 시스템의 구성 요소로, 배포할 수 있는 가장 작은 단위다. 자바의 경우 jar 파일이 컴포넌트다.
컴포넌트는 멋지고 깔끔한 인터페이스로 감싸진 연관된 기능들의 묶음으로, 애플리케이션과 같은 실행 환경 내부에 존재한다.
컴포넌트 기반 패키지의 주된 이점은 오직 한 곳만 둘러보면 된다는 점이다.
구현 세부사항엔 항상 문제가 있다.
세부사항을 잘못 구현하면 아키텍처가 빠르게 흐트러질 수 있다.
조직화 vs 캡슐화
모든 타입을 public으로 지정한다면, 패키지는 단순히 조직화를 위한 매커니즘으로 전력하여 캡슐화를 위한 매커니즘이 될 수 없다.
패키지를 사용하는 이점이 없다. 따라서 패키지를 사용하지 않는 것과 같다.
패키지를 무시해 버리면 어떤 아키텍처 스타일로 만들려고 하는지는 아무런 의미가 없어진다.
자바의 접근 지시자가 완벽하지는 않지만, 무시하면 사서 고생길
다른 결합 분리 모드
프로그래밍 언어가 제공하는 방법 외에도 소스 코드 의존성을 분리하는 방법 존재 (ex. java 9 모듈 시스템)
소스 코드 수준에서 의존성을 분리하는 것도 가능
결론: 빠져 있는 조언
최적의 설계를 꾀했더라도, 구현 전략에 얽힌 복잡합을 고려하지 않으면 설계가 순식간에 망가질 수도 있다는 사실을 강조
설계를 어떻게 해야만 원하는 코드 구조로 매핑할 수 있을지, 그 코드를 어떻게 조직화할지, 런타임과 컴파일타임에 어떤 결합 분림 모드를 적용할지를 고민
가능하다면 선택사항은 열어두되, 실용주의적으로 행하라.
그리고 팀의 규모, 기술 수준, 해결책의 복잡성을 일정과 예산이라는 제약과 동시에 고려하라
선택된 아키텍처 스타일을 강제하는 데 컴파일러의 도움을 받을 수 있을지 고민해라.
데이터 모델과 같은 다른 영역에 결합되지 않도록 주의
구현 세부사항에는 항상 문제가 있다.
참조
- 클린 아키텍처(Clean Architecture)