111 lines
9.6 KiB
Markdown
111 lines
9.6 KiB
Markdown
---
|
||
title: The Onion Architecture (Part 1) — Jeffrey Palermo 원형
|
||
source_type: official-doc
|
||
url: https://jeffreypalermo.com/2008/07/the-onion-architecture-part-1/
|
||
archive_url:
|
||
status: raw
|
||
confidence: high
|
||
tags: [ca-architecture-layout, onion, palermo, dependency-inversion, official-doc]
|
||
related_projects: [ca-skeleton-operational-contract]
|
||
related_branches: [feature-architecture-enforcement-rules, feature-skeleton-package-blueprint-contract, feature-domain-feature-onboarding-contract]
|
||
created: 2026-05-22
|
||
last_reviewed: 2026-05-27
|
||
---
|
||
|
||
# The Onion Architecture (Part 1) — Jeffrey Palermo 원형
|
||
|
||
> Layer: `raw/official-docs/` — Jeffrey Palermo 2008 원형 글 발췌. Hexagonal 과 자주 혼동되지만 "layer 가 명시적이고 동심원으로 그려진다" 는 점에서 다름.
|
||
> ca-tmpl `Topic 1 — Architecture Layout` 대안 비교 (대안 5: onion). 본 자료는 개인 블로그이나 **원저자 1차 자료**이므로 `official-doc` 으로 분류 (회사 표준은 아님).
|
||
|
||
## Parent / 활용 branch (필수)
|
||
|
||
> 이 자료는 혼자 존재하지 않는다. ca-tmpl architecture 결정 비교군의 한 축.
|
||
|
||
| Branch | 이 자료가 정당화하는 결정 |
|
||
|---|---|
|
||
| [[raw/branch-notes/feature-architecture-enforcement-rules]] | "all coupling is toward the center" 원칙을 enforcement rule 로 표현 가능한지 비교 — outer→inner 단방향 의존성 강제 근거 |
|
||
| [[raw/branch-notes/feature-skeleton-package-blueprint-contract]] | layer-first 동심원 vs ca-tmpl feature-first 의 대안 비교 baseline (대안 5: onion) |
|
||
| [[raw/branch-notes/feature-domain-feature-onboarding-contract]] | 새 feature 추가 시 동심원 layer 어디에 배치하는지 가이드 부재 — feature-first 의 상대적 우위 비교 근거 |
|
||
|
||
특정 branch 없이 foundational 조사로 수집한 경우:
|
||
|
||
- [[raw/project-notes/ca-skeleton-operational-contract]] — §20 Skeleton Blueprint Contract / §19 Domain Application Readiness Contract 의 대안 비교 (대안 5: onion)
|
||
|
||
## 컨텍스트
|
||
|
||
ca-tmpl 의 feature-first 결정에 대한 대안 5: Onion Architecture 원형. Hexagonal 과 자주 혼동되지만 "layer 가 명시적이고 동심원으로 그려진다" 는 점에서 다름. ca-tmpl 의 4-layer(presentation/application/domain/infrastructure) 가 Onion 의 layer 정의와 어떻게 다른지 비교 baseline.
|
||
|
||
## 출처 / Source
|
||
|
||
- 원본 URL: https://jeffreypalermo.com/2008/07/the-onion-architecture-part-1/
|
||
- 아카이브 URL: (미수집)
|
||
- 저자 / 조직: Jeffrey Palermo (개인 블로그 — Headspring co-founder)
|
||
- 발행일: 2008-07 (Part 1), 후속 Part 2~4 (2008–2013)
|
||
- 마지막 확인일: 2026-05-27
|
||
- **재검증 상태 (2026-05-27)**: WebFetch 로 Palermo 2008 블로그 재확인 완료 — 5/5 핵심 인용 verbatim 매칭. C2 ("all coupling is toward the center") 는 원문에 "In other words, " prefix 가 있어 revised verbatim 추가. 개인 블로그 1차 자료이나 회사 표준은 아님 — `official-doc` 분류는 "원저자 1차 자료" 의미. Strength 는 `official-reference` (원저자가 직접 작성한 패턴 정의의 1차 출처).
|
||
|
||
## 핵심 인용 / Key quotes (verbatim)
|
||
|
||
> [§Onion architecture rule] "The fundamental rule is that all code can depend on layers more central, but code cannot depend on layers further out from the core."
|
||
|
||
> [§Dependency direction — 2026-05-25 capture] "all coupling is toward the center"
|
||
>
|
||
> [§Dependency direction — 2026-05-27 verified] "In other words, all coupling is toward the center."
|
||
|
||
> [§Problems of traditional layering] "The biggest offender (and most common) is the coupling of UI and business logic to data access."
|
||
|
||
> [§Database position] "The database is not the center. It is external."
|
||
|
||
> [§DIP] "The Onion Architecture relies heavily on the Dependency Inversion principle."
|
||
|
||
## Claims Extracted / 추출된 주장
|
||
|
||
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|
||
|---|---|---|---|---|---|
|
||
| ONION-PAL-C1 | Onion 의 **fundamental rule**: 모든 코드는 더 중심에 있는 layer 에 의존할 수 있으나, 코어로부터 더 바깥에 있는 layer 에는 의존할 수 없다 | [§Onion architecture rule] "The fundamental rule is that all code can depend on layers more central, but code cannot depend on layers further out from the core." [2026-05-27 verified] | `official-reference` | Onion 패턴의 의존성 방향 정의 | "layer 의 경계가 패키지인지 모듈인지 namespace 인지" 는 본 인용에 없음 — 구현 선택은 별도 |
|
||
| ONION-PAL-C2 | 모든 coupling 은 중심을 향한다 — outer→inner 단방향 | [§Dependency direction] [2026-05-25 capture] "all coupling is toward the center" → [2026-05-27 verified] "In other words, all coupling is toward the center." (원문에 "In other words, " prefix 존재) | `official-reference` | Onion 패턴의 결합 방향 | "중심" 이 정확히 domain entity 인지 domain service 인지 application service 인지는 본 인용에 없음 (Palermo Part 2~4 별도) |
|
||
| ONION-PAL-C3 | 전통적 layering 의 가장 큰 문제는 UI 와 business logic 이 data access 에 결합되는 것 (Onion 이 해결하려는 동기) | [§Problems of traditional layering] "The biggest offender (and most common) is the coupling of UI and business logic to data access." [2026-05-27 verified] | `official-reference` | 전통적 N-tier 의 문제 진단 | "data access" 가 ORM 인지 raw SQL 인지 repository pattern 인지는 본 인용에 없음 |
|
||
| ONION-PAL-C4 | Database 는 시스템의 중심이 아니라 외부 (external) — Onion 의 핵심 발상 중 하나 | [§Database position] "The database is not the center. It is external." [2026-05-27 verified] | `official-reference` | DB-centric 설계에 대한 반박 | DB schema-first 개발 자체를 금지한다는 뜻은 아님 — 의존성 방향만 제한 |
|
||
| ONION-PAL-C5 | Onion Architecture 는 Dependency Inversion principle 에 크게 의존 | [§DIP] "The Onion Architecture relies heavily on the Dependency Inversion principle." [2026-05-27 verified] | `official-reference` | DIP 적용 사상 | DIP 적용의 구체 방법 (interface 위치, factory 패턴 사용 등) 은 본 인용에 없음 |
|
||
|
||
## Usage Boundaries / 적용 경계
|
||
|
||
- **이 자료가 직접 증명하는 것**:
|
||
- `ONION-PAL-C1` ~ `C5`: Onion 의 fundamental rule, 결합 방향, 동기 (UI/BL ↔ DA 결합 문제), DB 의 외부 위치, DIP 의존
|
||
- **이 자료가 증명하지 않는 것**:
|
||
- Onion 의 정확한 layer 명명 (Domain Model / Domain Services / Application Services / Outer) — user 메모이며 Part 1 인용에 없음, Part 2~4 별도 확인 필요
|
||
- "feature" 개념 부재 — Onion 원형이 feature 분할에 대해 침묵하는 것은 user 해석 (인용 자체가 부재를 보이지는 않음)
|
||
- Onion ≠ Hexagonal 의 명확한 구분 (Palermo 본인이 두 패턴의 관계를 어떻게 설명했는지는 별도)
|
||
- 동심원 다이어그램의 정확한 컨벤션 (몇 개 layer 여야 하는지 등)
|
||
- **company-tech-blog 사례가 Palermo 의 official 의도라는 보장** — 4-tenets 등 user 메모의 일부는 Part 2~4 또는 별도 자료에 근거
|
||
- **내 프로젝트에 적용하려면 추가 확인이 필요한 것**:
|
||
- ca-tmpl 의 infrastructure layer 가 Onion 의 outer layer 와 정확히 동일한지 (Onion 은 infrastructure 만이 아니라 UI / tests 도 outer)
|
||
- feature-first 의 feature 가 Onion 의 어느 layer 에 해당하는지 — Onion 에는 feature 개념 자체가 없으므로 매핑 불가능할 수도 있음
|
||
- Palermo Part 2~4 의 정확한 4 tenets verbatim 추출 (2008 ~ 2013 시리즈 별도)
|
||
|
||
## 메모 / Notes (내 프로젝트 해석)
|
||
|
||
> 본 섹션은 자료 직접 인용 아님. ca-tmpl 비교 컨텍스트 해석.
|
||
|
||
- 적용 시나리오: 도메인 모델이 풍부하고 (Rich Domain Model) infrastructure 변경 가능성이 큰 시스템.
|
||
- Palermo 의 4 tenets (2008, user 메모 — Part 2~4 별도 검증 필요): (1) 독립 객체 모델 중심 (2) 내부 layer 가 인터페이스 정의 (3) 외부 layer 가 구현 (4) 의존성 방향은 외→내 일방.
|
||
- 장점: layer 정의가 명시적 (Domain Model / Domain Services / Application Services / Outer) 이라 학습 진입이 Hexagonal 보다 쉬움 (user 해석).
|
||
- 단점: layer 가 동심원 → "feature" 개념 없음. 도메인이 많으면 도메인 layer 가 비대해짐.
|
||
- ca-tmpl(feature-first) 와의 차이: Onion 은 **layer 가 최상위**. ca-tmpl 은 **feature 가 최상위**, layer 가 feature 내부. 의존성 방향(outer→inner) 은 ca-tmpl 도 동일하게 적용 가능하나, Onion 원형에는 feature 분할 가이드가 없음 → 5개 대안 중 ca-tmpl 결정과 **가장 다른 축**.
|
||
- 신뢰도: 원저자 1차 자료 → `official-doc` 수준으로 취급 가능. 단 회사 공식 표준은 아님(개인 블로그). RFC / Spring docs 같은 vendor doc 수준의 corroboration 으로는 부족.
|
||
|
||
## Related / 관련
|
||
|
||
- 같은 주제 다른 official-doc:
|
||
- [[raw/official-docs/hexagonal-cockburn-wikipedia-summary]] (자주 혼동되는 Hexagonal 원형)
|
||
- [[raw/official-docs/hexagonal-thombergs-buckpal-github]] (Spring/Java reference 구현)
|
||
- [[raw/official-docs/modulith-spring-official-doc]] (modular monolith 공식 대안)
|
||
- 같은 주제 company-tech-blog:
|
||
- [[raw/company-tech-blogs/hexagonal-woowahan-techblog-2023]] (한국 대기업 hexagonal 사례 — onion 과 다른 축)
|
||
- 인용하는 branch / project:
|
||
- [[raw/branch-notes/feature-architecture-enforcement-rules]]
|
||
- [[raw/branch-notes/feature-skeleton-package-blueprint-contract]]
|
||
- [[raw/branch-notes/feature-domain-feature-onboarding-contract]]
|
||
- [[raw/project-notes/ca-skeleton-operational-contract]]
|
||
- 인용한 wiki 요약: (미작성)
|