10 KiB
10 KiB
title, source_type, url, archive_url, status, confidence, tags, related_projects, related_branches, created, last_reviewed
| title | source_type | url | archive_url | status | confidence | tags | related_projects | related_branches | created | last_reviewed | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| The Clean Architecture — Uncle Bob (cleancoder blog 원문) | official-doc | https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html | raw | medium |
|
|
|
2026-05-27 | 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-blogstrength) - ca-tmpl 의
domain/application/adapter/infrastructure4-패키지 분할이 Clean Architecture 의 4동심원과 1:1 매핑된다는 점 (매핑 결정은 별도 wiki/projects 문서에서 수행) - Spring / JPA 같은 특정 기술의 어느 클래스가 어느 동심원에 속하는지의 구체 (책 Clean Architecture 2017 본문, 또는 별도 가이드라인 필요)
- DTO 변환을 어느 레이어가 책임지는지의 결정 (Use Case 진입/이탈, Controller, Mapper 중 어디인지)
- 이 구조가 공식 표준 이거나 업계 best practice 라는 점 — 본 자료는 Uncle Bob 의 personal blog 이며, ISO/IEEE/OMG 등의 표준 문서가 아님 (
- 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- 본 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:
- 인용하는 project:
- 이 자료를 인용한 wiki 요약: (미작성)