llm-wiki/raw/official-docs/arch-clean-architecture-uncle-bob.md

---
title: The Clean Architecture — Uncle Bob (cleancoder blog 원문)
source_type: official-doc
url: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
archive_url:
status: raw
confidence: medium
tags: [architecture, clean-architecture, dependency-rule, layered-architecture, ddd, ca-skeleton-operational-contract]
related_projects: [ca-skeleton-operational-contract]
related_branches: [feature-repository-access-permission-contract, feature-architecture-enforcement-rules, feature-skeleton-package-blueprint-contract]
created: 2026-05-27
last_reviewed: 2026-05-27
---

# The Clean Architecture — Uncle Bob (cleancoder blog 원문)

> Layer: `raw/official-docs/` — Robert C. Martin (Uncle Bob) 의 2012-08-13 "Clean Architecture" 포스트 원문 발췌. Dependency Rule + 4개 동심원(Entities / Use Cases / Interface Adapters / Frameworks & Drivers) 의 1차 출처.

## Parent / 활용 branch (필수)

| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| [[raw/branch-notes/feature-repository-access-permission-contract]] | D1 (도메인 → 인프라 의존 금지) 와 D5 (Repository interface 가 domain 측에 위치) 의 1차 근거 — Dependency Rule 의 "source code dependencies can only point inwards" |
| [[raw/branch-notes/feature-architecture-enforcement-rules]] | 4개 동심원 사이의 의존성 방향이 ArchUnit 규칙으로 강제할 layer 정의의 기준점 |
| [[raw/branch-notes/feature-skeleton-package-blueprint-contract]] | ca-tmpl 패키지 청사진 (`domain/`, `application/`, `adapter/`, `infrastructure/`) 이 Clean Architecture 의 어느 동심원에 매핑되는지 결정 근거 |

## 컨텍스트

ca-tmpl skeleton 의 모든 의존성 규칙·패키지 청사진·ArchUnit 강제 규칙이 "어느 레이어가 어느 레이어를 참조할 수 있는가" 를 결정해야 한다. Clean Architecture 원문이 그 single source of truth 후보 중 하나(다른 후보: Cockburn Hexagonal). 본 raw 는 Uncle Bob 의 원문 quote 만 보관하며, 적용 결론은 wiki/concepts 에서 별도 정리한다.

## 출처 / Source

- 원본 URL: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
- 아카이브 URL:
- 저자 / 조직: Robert C. Martin (Uncle Bob) — personal blog (`blog.cleancoder.com`)
- 발행일: 2012-08-13
- 마지막 확인일: 2026-05-27

## 핵심 인용 / Key quotes (verbatim)

> [§The Dependency Rule] "source code dependencies can only point inwards"

> [§The Dependency Rule] "Nothing in an inner circle can know anything at all about something in an outer circle"

> [§Entities] "Entities encapsulate Enterprise wide business rules"

> [§Use Cases] "application specific business rules. It encapsulates and implements all of the use cases"

> [§Interface Adapters] "set of adapters that convert data from the format most convenient for the use cases and entities"

> [§Frameworks and Drivers] "outermost layer is generally composed of frameworks and tools such as the Database, the Web Framework"

> [§Crossing boundaries] "we would arrange interfaces and inheritance relationships such that the source code dependencies oppose the flow of control"

> [§What data crosses the boundaries] "isolated, simple, data structures are passed across the boundaries"

## Claims Extracted / 추출된 주장

| Claim ID | Claim | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| CLEAN-ARCH-UB-C1 | Clean Architecture 의 핵심 규칙은 **소스 코드 의존성이 오직 안쪽으로만 향한다** (Dependency Rule) | [§The Dependency Rule] "source code dependencies can only point inwards" | `engineering-blog` | Clean Architecture 를 채택한 시스템의 레이어 간 의존 방향 | 어떤 레이어가 "안쪽" 인지 자체는 본 한 줄 인용으로 결정되지 않음 — 동심원 정의(C3~C6) 와 결합되어야 의미를 가짐 |
| CLEAN-ARCH-UB-C2 | 안쪽 원(inner circle) 은 바깥쪽 원(outer circle) 의 어떤 것도 알아서는 안 된다 — 이름·타입·함수 모두 포함 | [§The Dependency Rule] "Nothing in an inner circle can know anything at all about something in an outer circle" | `engineering-blog` | 모든 동심원 경계 | 이 원칙이 컴파일 타임만 적용되는지 런타임에도 적용되는지의 구체는 본 인용에 없음 (실무에선 둘 다로 해석) |
| CLEAN-ARCH-UB-C3 | Entities 동심원은 **Enterprise wide business rules** 를 캡슐화한다 | [§Entities] "Entities encapsulate Enterprise wide business rules" | `engineering-blog` | 도메인 모델이 여러 application 에 공유되는 조직 | 단일 application 만 있는 프로젝트에서 Entities 와 Use Cases 의 경계가 어떻게 흐려지는지는 본 인용에 없음 |
| CLEAN-ARCH-UB-C4 | Use Cases 동심원은 application-specific business rules 를 담고 모든 use case 를 캡슐화·구현한다 | [§Use Cases] "application specific business rules. It encapsulates and implements all of the use cases" | `engineering-blog` | application layer / use case layer 식별 기준 | Use Case 가 transaction script 인지 interactor 객체인지 등 구현 형태는 본 인용에 없음 |
| CLEAN-ARCH-UB-C5 | Interface Adapters 동심원은 use cases 및 entities 에 가장 편리한 포맷과 외부 포맷(DB/Web) 사이를 변환하는 adapter 집합이다 | [§Interface Adapters] "set of adapters that convert data from the format most convenient for the use cases and entities" | `engineering-blog` | Controller / Presenter / Gateway 류 코드의 위치 결정 | 어떤 변환이 "가장 편리한" 포맷인지의 구체 기준은 본 인용에 없음 (DTO vs domain object 결정은 별도) |
| CLEAN-ARCH-UB-C6 | Frameworks and Drivers 동심원은 Database, Web Framework 등 frameworks and tools 로 구성된 outermost layer 다 | [§Frameworks and Drivers] "outermost layer is generally composed of frameworks and tools such as the Database, the Web Framework" | `engineering-blog` | Spring / JPA / 기타 framework 코드의 위치 결정 | 어느 framework 구성요소가 어느 인접 원과 직접 닿는지(예: ORM mapper vs Repository impl)의 분리 기준은 본 인용에 없음 |
| CLEAN-ARCH-UB-C7 | 의존성이 흐름의 방향과 반대로 향하도록 interface 와 상속을 배치한다 (의존성 역전 원칙의 실무 적용) | [§Crossing boundaries] "we would arrange interfaces and inheritance relationships such that the source code dependencies oppose the flow of control" | `engineering-blog` | use case 가 outer-layer 컴포넌트를 호출해야 하는 경계 | DI container / factory / abstract factory 중 어떤 메커니즘이 의무인지는 본 인용에 없음 (구현 선택지는 열려 있음) |
| CLEAN-ARCH-UB-C8 | 경계를 가로지를 때는 **isolated, simple, data structures** 만 전달해야 한다 | [§What data crosses the boundaries] "isolated, simple, data structures are passed across the boundaries" | `engineering-blog` | 레이어 간 메서드 시그니처 / DTO 정책 | ORM Entity 객체를 그대로 전달하면 안 된다는 강제 규칙으로 일반화 가능한지는 본 인용만으로는 결론낼 수 없음 (Uncle Bob 의 다른 글과 결합 필요) |

## Usage Boundaries / 적용 경계

- **이 자료가 직접 증명하는 것**:
  - `CLEAN-ARCH-UB-C1`, `C2`: Dependency Rule 의 정확한 phrasing (Uncle Bob 본인의 단어 선택)
  - `CLEAN-ARCH-UB-C3`~`C6`: 4개 동심원의 이름과 각각의 책임 정의
  - `CLEAN-ARCH-UB-C7`: 의존성 역전을 통한 boundary crossing 의 메커니즘 (interface + inheritance)
  - `CLEAN-ARCH-UB-C8`: 경계를 넘는 데이터의 형태 제약 (isolated, simple)
- **이 자료가 증명하지 않는 것**:
  - 이 구조가 **공식 표준** 이거나 업계 best practice 라는 점 — 본 자료는 Uncle Bob 의 personal blog 이며, ISO/IEEE/OMG 등의 표준 문서가 아님 (`engineering-blog` strength)
  - ca-tmpl 의 `domain` / `application` / `adapter` / `infrastructure` 4-패키지 분할이 Clean Architecture 의 4동심원과 1:1 매핑된다는 점 (매핑 결정은 별도 wiki/projects 문서에서 수행)
  - Spring / JPA 같은 특정 기술의 어느 클래스가 어느 동심원에 속하는지의 구체 (책 *Clean Architecture* 2017 본문, 또는 별도 가이드라인 필요)
  - DTO 변환을 어느 레이어가 책임지는지의 결정 (Use Case 진입/이탈, Controller, Mapper 중 어디인지)
- **내 프로젝트에 적용하려면 추가 확인이 필요한 것**:
  - 본 4동심원과 ca-tmpl 의 실제 패키지 청사진의 매핑표 ([[raw/branch-notes/feature-skeleton-package-blueprint-contract]] 에서 결정)
  - Dependency Rule 을 ArchUnit 으로 강제할 때의 구체 규칙 표현 ([[raw/branch-notes/feature-architecture-enforcement-rules]])
  - "isolated, simple data structures" 의 ca-tmpl 내 구체 정의 (record? immutable POJO? DTO 인터페이스 규약?)

## 메모 / Notes

- 본 글은 Uncle Bob 이 동일 주제를 다룬 책 *Clean Architecture* (Prentice Hall, 2017) 의 모티프 원문에 해당. 책 본문이 더 상세하지만 본 블로그 글이 가장 자주 인용되는 단일 출처.
- Cockburn Hexagonal (1차 출처: [[raw/official-docs/arch-hexagonal-cockburn]]) 과의 핵심 차이는 **레이어 수와 명명** — Clean Architecture 는 4개 동심원으로 더 세분화, Hexagonal 은 inside/outside + ports 로 더 추상화. ca-tmpl 의 4-패키지 분할은 양쪽 모두에서 정당화 가능.
- 본 글이 personal blog 라는 점은 strength 측면에서 중요. ArchUnit 같은 vendor 도구의 layered-architecture API 가 "Clean Architecture" 라는 이름을 인용한다고 해서 본 글이 자동으로 official-vendor-doc 으로 격상되지는 않음.

## Related / 관련

- 같은 주제 다른 raw:
  - [[raw/official-docs/arch-hexagonal-cockburn]] (Cockburn 원문 — Hexagonal/Ports & Adapters)
  - [[raw/official-docs/archunit-user-guide]] (Layer rule 강제 도구)
- 이 자료를 인용하는 branch:
  - [[raw/branch-notes/feature-repository-access-permission-contract]]
  - [[raw/branch-notes/feature-architecture-enforcement-rules]]
  - [[raw/branch-notes/feature-skeleton-package-blueprint-contract]]
- 인용하는 project:
  - [[raw/project-notes/ca-skeleton-operational-contract]]
- 이 자료를 인용한 wiki 요약: (미작성)