Layered, Clean & Hexagonal Architecture

1. Overview

계층형, 클린 및 헥사고날 아키텍처(Layered, Clean & Hexagonal Architecture, LCH)는 소프트웨어의 핵심 가치인 '비즈니스 규칙'이 데이터베이스나 웹 프레임워크 같은 외부 기술 사정에 휘둘리지 않도록 물리적 성벽을 쌓는 설계 기술입니다.

많은 시스템이 외부 라이브러리 의존성 때문에 교체나 테스트가 불가능한 '기술 부채' 상태에 빠집니다. 학습자는 의존성의 방향을 안쪽(심장부)으로 흐르게 하는 **의존성 역전 원칙(DIP)**의 수리적 구현을 배웁니다. 특히, 전통적인 계층형(Layered) 구조의 한계를 넘어, 인터페이스를 통해 외부와 소통하는 포트와 어댑터(Ports and Adapters) 모델과, 원형의 경계를 가진 클린 아키텍처의 물리 구조를 익칩니다. 이를 통해 기술이 변해도 비즈니스는 살아남는 영속적 시스템 설계 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• Layered Physics: 프레젠테이션, 서비스, 데이터 접근 계층의 순차적 물리 의존성
• Hexagonal (Ports & Adapters): 인바운드/아바운드 포트와 물리적 어댑터의 분리
• Clean Architecture Anatomy: 엔티티(Entity)와 유스케이스(Use Case)의 중심 배치 물리학
• Dependency Inversion: 상위 수준 모듈이 하위 수준 모듈에 의지하지 않게 하는 수리적 장치

Out-of-Scope

• 단위 서비스 간의 상호 호출 관계 (07-01-01 영역으로 위임)
• 특정 프로그래밍 언어의 인터페이스 문법 상세 (05-02-XX 영역에서 분담)

Boundaries

• LCH vs. Design Patterns: 디자인 패턴(07-01-04)이 '객체 간의 국지적 협력'에 집중한다면, LCH는 '시스템 전반의 구조적 배치와 의존성 흐름'에 집중하여 구분합니다.

3. Counterexample

• 단순히 "폴더 나누기"라 설명하는 것은 LCH 학습이 아닙니다. 왜 도메인 엔티티가 외부의 SQL 라이브러리를 임포트(Import) 하는 순간 전체 아키텍처가 물리적으로 붕괴되는지 수리적으로 증명할 수 있어야 하며, 단순히 인터페이스만 쓴다고 해서 아키텍처가 유연해지지 않는 '인터페이스 역설'을 논증하지 못한다면 LCH의 정수를 이해하지 못한 것입니다.

4. Prerequisites

• Object-Oriented Programming (Basic): 다형성과 캡슐화 이해가 필수입니다. (05-02-01 OOP)
• Software Design Principles (Recommended): SOLID 원칙 기초 이해가 권장됩니다. (09-01-01 기초 역량)

5. Learning Map

1. The Layered Trap: 계층을 나누었음에도 왜 여전히 DB에 종속되는지 물리적 원인을 파악합니다.
2. Inverting the Flow: 의존성의 화살표를 꺾어 비즈니스 심장부를 물리적으로 고립시킵니다.
3. Pluggable Adapters: 포트라는 구멍을 뚫고, 어떤 기술(DB, CLI, Web)이든 끼웠다 뺄 수 있는 구조를 배웁니다.
4. The Fortress of Logic: 어떤 폭풍(기술 변경)에도 흔들리지 않는 순수 도메인 영토를 완성합니다.

6. Learning Topics

Basic

Core: 계층형 아키텍처의 물리적 한계 (Layered Architecture)

• Why to Learn: 가장 직관적이지만 가장 위험한 '하향식 의존성'의 폐해를 알기 위해서입니다.
• What to Learn:
  • Classic 3-Tier: UI -> Business -> Data Access의 물리적 연결
  • Transitivity: 상위 계층이 하위 계층의 모든 변경에 물리적으로 영향을 받는 현상
  • Leakage: 하위 계층의 관심사(SQL 등)가 상위로 흘러넘치는 물리적 결함
• How to Learn:
  • DB 스키마가 바뀌었을 때 UI 코드까지 고쳐야 하는 상황을 수리적으로 추적 실습
  • 계층 간 직접 참조로 인해 코드 가독성은 좋으나 테스트가 불가능해지는 지점 도출
• Implement: 전통적인 3계층 구조를 가진 간단한 CRUD 애플리케이션 프로토타입

Recommended

Core: 헥사고날 아키텍처와 포트 설계 (Ports & Adapters)

• Why to Learn: 외부 세계와 로직을 완전히 격리하여 '모킹(Mocking)' 없이도 하드웨어 독립적인 테스트를 하기 위함입니다.
• What to Learn:
  • The Core Engine: 오직 비즈니스 언어로만 기록된 중심 영역
  • Ports (Interfaces): 시스템 안팎으로 흐르는 데이터의 통로 명세
  • Adapters (Implementation): 외부 기술(MySQL, AWS S3)을 포트에 연결하는 물리적 변환기
• How to Learn:
  • '데이터 저장' 기능을 가진 포트를 만들고, 이를 메모리 맵과 실제 DB로 각각 갈아 끼우는 물리적 장착 실습
  • 외부 API 변경이 시스템 내부로 전파되지 않도록 어댑터에서 방어하는 수리 모델 분석
• Implement: 포트 주입(Dependency Injection)을 통해 데이터 저장소를 변경할 수 있는 서비스 아키텍처

Practical

Core: 클린 아키텍처의 의존성 규칙 (Clean Architecture)

• Why to Learn: 소프트웨어의 수명을 늘리고 유지보수 비용을 하드웨어 성능과 무관하게 일정하게 유지하기 위해서입니다.
• What to Learn:
  • The Circle of Power: Entities -> Use Cases -> Controllers -> External Agents의 원형 배치
  • Dependency Rule: 의존성은 언제나 안쪽 원으로만 향해야 한다는 물리적 철칙
  • Crossing Boundaries: 계층 경계를 넘을 때 데이터를 단순 객체(DTO)로 물리 변환하는 법
• How to Learn:
  • 복잡한 비즈니스 로직을 '엔티티'와 '유스케이스'로 분리하고, 그 사이의 수리적 결합도를 측정하는 실습
  • 프레임워크가 제공하는 장치 없이 순수 언어로만 핵심 로직을 작성해 보며 물리적 독립성 확인
• Implement: 클린 아키텍처 폴더 구조(Domain, Application, Infrastructure)를 갖춘 프로젝트 스캐폴딩

Advanced

Core: 도메인 중심 아키텍처의 통합 거버넌스 (System Integrity)

• Why to Learn: 대규모 팀이 각자의 모듈을 개발하면서도 전체 시스템의 수리적 질서를 유지하기 위함입니다.
• What to Learn:
  • Context Mapping in Arch: 아키텍처 패턴과 DDD 도메인 경계의 물리적 일치
  • Evolutionary Architecture: 변화에 강한 구조적 유연성을 수치화하는 법
  • Socio-Technical Alignment: 팀 구조와 아키텍처 경계의 물리적 상관관계(Conway's Law)
• How to Learn:
  • 아키텍처 원칙 위반을 자동으로 감지하는 '피트니스 함수(Fitness Function)' 설계 실습
  • 서로 다른 아키텍처(Layered vs Clean)를 사용하는 시스템 간의 물리적 통합 전략 산출
• Implement: 패키지 간 의존성 방향을 검증하는 아키텍처 테스트 코드(ArchUnit 등 활용)

7. Terminology

8. References

Primary

• [P2] SWEBOK v4.0 - Software Design / Software Structure and Architecture — Structural context.
• [P1] CS2023 - SE/Software Engineering (Architectural styles) — Core requirements.

Secondary

• [Clean Architecture] Robert C. Martin — The definitive guide to the circular model.
• [Get Your Hands Dirty on Clean Architecture] Tom Hombergs — Practical hexagonal patterns.

Industry

• [Netflix: Hexagonal Architecture for Developer Productivity] — Large scale application case.
• [AWS: Implementing Clean Architecture on AWS] — Cloud-specific implementation.

9. Final Checklist

Primary

• '계층형 아키텍처'에서 '데이터 접근 계층'에 대한 의존성을 끊기 위해 **DIP(의존성 역전)**를 어떻게 물리적으로 적용하는지 설명 가능한가? (P1)
• '클린 아키텍처'의 원형 다이어그램에서 '의존성 방향'이 왜 안쪽으로만 향해야 하는지 그 수리적 근거를 기술할 수 있는 가? (P1)

Secondary

• '포트(Port)'와 '어댑터(Adapter)'의 차이를 정의하고, 새로운 데이터베이스 도입 시 어느 쪽 코드를 물리적으로 수정해야 하는지 답변할 수 있는 가?
• 엔티티(Entity) 영역에 외부 라이브러리(애노테이션 등)가 침투했을 때 발생하는 아키텍처적 부작용을 소통 가능한가?

Industry

• 대규모 엔터프라이즈 환경에서 '프레임워크 독립성'이 장기적인 유지보수 하드웨어 비용에 미치는 수리적 영향을 분석할 수 있는 가? (SFIA)
• 팀 프로젝트 진행 시, 관심사 분리를 통해 '병렬 개발' 효율이 물리적으로 얼마나 향상되는지 제안할 수 있는 가?