9.6 KiB
9.6 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 Onion Architecture (Part 1) — Jeffrey Palermo 원형 | official-doc | https://jeffreypalermo.com/2008/07/the-onion-architecture-part-1/ | raw | high |
|
|
|
2026-05-22 | 2026-05-27 |
The Onion Architecture (Part 1) — Jeffrey Palermo 원형
Layer:
raw/official-docs/— Jeffrey Palermo 2008 원형 글 발췌. Hexagonal 과 자주 혼동되지만 "layer 가 명시적이고 동심원으로 그려진다" 는 점에서 다름. ca-tmplTopic 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:
- 인용한 wiki 요약: (미작성)