Clean Architecture 정리 - 5부 34 다양한 아키텍처

1) 계층 기반 패키지(수평 계층형 아키텍처)

정의

• controller → service → data처럼 유사 역할끼리 수평으로 묶는 구조임.
• "엄격한 계층형 아키텍처"는 바로 아래 계층에만 의존함.

장점

• 빠르게, 기능이 동작하는 서비스를 개발할 수 있다.

문제

• 서로 다른 도메인도 겉모습이 크게 컨트롤러→서비스→리포지터리로 같아 보임.
• 도메인 정체성이 드러나지 않음.

---

2) 기능 기반 패키지 (수직 슬라이싱)

정의

• 연관 기능/도메인 개념을 세로로 묶음. 예: orders/, payments/ 등.

장점 

• 한 패키지 안에, 관련 기능의 코드가 담겨 있음, 찾기 쉬움

단점

• 저수준 정책의 변화도 컴포넌트 전체의 빌드, 테스트, 배포에 영향을 미침

---

3) 포트와 어댑터 (헥사고날/클린)

정의

• 내부(도메인/애플리케이션) 과 외부(UI, DB, 3rd-party, Framework, .. )를 포트(추상)로 분리.
• 외부가 내부에 의존함.

장점

• 변경이 큰 외부에 의해, 중요도가 높은 내부가 영향을 받지 않음

단점

• 널리 사용되고 있지 않기 때문에, 팀원들이 아키텍처의 이해를 필요로 함

---

4) 커스텀 아키텍처

• 프로젝트 성격에 맞게 수평/수직/포트-어댑터를 혼합

---

5)의존성 유지하기

A→B→C 순서로 의존성 설계,
하지만 설계 방침을 인지 못하고 A→C 지름길 생기는 경우가 많음.

 

해결 가이드

• 레지스트리/저장소 스코핑
  A가 보는 저장소를 B만 보게 제한(사설 Maven/Nexus/Artifactory content filter, npm @org/ 스코프 + .npmrc).
• 의존성 금지 규칙:
  • Gradle: componentSelection/resolutionStrategy로 com.mycorp.c:* 후보를 reject; 버전 카탈로그와 함께 사용. dependencyVerification은 체크섬/서명 검증 등 승인된 아티팩트만 허용 용도.
  • Maven maven-enforcer-plugin의 bannedDependencies.
  • JS: ESLint no-restricted-imports / Nx enforceModuleBoundaries.
• 전이 의존 차단: B→C는 implementation(비공개). B의 공개 API에서 C 타입/예외/상수 노출 금지(포트/DTO로 캡슐화).
• CI 정책: ArchUnit/ESLint boundaries로 “A→C 금지”를 테스트로 고정하고, SBoM(CycloneDX) + OPA/Conftest로 금지 그룹 발견 시 실패.
• 런타임 차단(선택): 쿠버네티스 NetworkPolicy, 서비스 메시(Istio)로 A→C 트래픽 금지.
  게이트웨이 라우팅 정책으로 A의 클라이언트 권한을 C에서 막음

 

※ 본 글은 『Clean Architecture』(로버트 C. 마틴 저) 5부 34장을 기반으로 학습 목적으로 요약한 글입니다.

※ 이 글은 책의 내용을 요약한 것으로, 원문 없이 읽을 경우 오해의 여지가 있을 수 있습니다. 정확한 이해를 위해 원서의 정독을 권장합니다.