8.9 KiB
title, source_type, url, archive_url, status, confidence, tags, related_branches, related_projects, created, last_reviewed
| title | source_type | url | archive_url | status | confidence | tags | related_branches | related_projects | created | last_reviewed | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Onion Architecture (Allegro Tech Blog) | company-tech-blog | https://blog.allegro.tech/2023/02/onion-architecture.html | raw | medium |
|
|
|
2026-05-22 | 2026-05-27 |
Onion Architecture (Allegro Tech Blog)
Layer:
raw/company-tech-blogs/— Allegro (폴란드 e-commerce) 의 Onion Architecture 해설 + Hexagonal 비교. 공식 표준 아닌 회사 사례. ca-tmpl 의 architecture-layout 대안 5종 중 "onion" 대안의 reference.
Parent / 활용 branch (필수)
| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| raw/branch-notes/feature-architecture-enforcement-rules | Onion 의 명시적 layer 분리 + dependency direction (outside → inside) 가 ArchUnit 규칙으로 표현될 때의 reference |
| raw/branch-notes/feature-skeleton-package-blueprint-contract | 패키지 blueprint 결정 시 layer-first (domain/application/infrastructure) 어휘의 사례 |
| raw/branch-notes/feature-domain-feature-onboarding-contract | 신규 도메인 추가 시 layer-first vs feature-first 분할 priority 비교 근거 |
| raw/project-notes/ca-skeleton-operational-contract | §19 Domain Application Readiness, §20 Skeleton Blueprint 의 onion 대안 reference |
출처 / Source
- 원본 URL: https://blog.allegro.tech/2023/02/onion-architecture.html
- 아카이브 URL: (미수집)
- 저자: Tomasz Tarczyński
- 조직: Allegro (폴란드 최대 e-commerce 플랫폼)
- 발행일: 2023-02-13
- 마지막 확인일: 2026-05-27
왜 저장했는지 / Why archived
ca-tmpl 의 feature-first 결정에 대한 대안 5: Onion Architecture 의 대기업 실 적용 관점 + Hexagonal 과의 명시적 비교 자료. Palermo 원문이 .NET 맥락이라 Java/Spring 적용 관점이 부족한 점을 보강.
핵심 인용 / Key quotes (verbatim)
[§Definition] "Onion Architecture is a software architectural style which strongly promotes the separation of concerns between the most important part of a business application — the domain code — and its technical aspects like HTTP or database."
[§Comparison with Hexagonal] "It can be successfully used as an alternative to a popular Hexagonal / Ports and Adapters architecture, and as such is predominantly used in the backend, business applications and services."
[§Comparison with Hexagonal] "The main difference I've found in the implementations of Hexagonal Architecture and Onion Architecture lies mostly in the overall, more structured approach to the code layout of the latter."
[§Core Objective] "They all have the same objective, which is the separation of concerns. They all achieve this separation by dividing the software into layers."
[§Layer Structure] "There are three main layers in Onion Architecture: The domain layer, The application layer, The infrastructure layer each of which has its responsibilities."
[§Dependency Direction] "Every outer layer sees classes from all inner layers, not only the one directly below. Moreover, the dependency direction always goes from the outside to the inside, never the other way around."
[§Dependency Coupling] "Coupling is towards the centre of The Onion — expressed by the relationship between the layers."
Claims Extracted / 추출된 주장
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| ALLEGRO-ONION-C1 | Onion Architecture 는 도메인 코드와 기술적 측면 (HTTP, DB) 의 관심사 분리를 강력하게 추구하는 아키텍처 스타일 | [§Definition] "Onion Architecture is a software architectural style which strongly promotes the separation of concerns between the most important part of a business application — the domain code — and its technical aspects like HTTP or database." | company-case-study |
비즈니스 어플리케이션의 도메인 중심 설계 | Onion 만이 SoC 를 달성할 수 있다는 뜻 아님 — Hexagonal, Clean, Modulith 등도 동일 목표 |
| ALLEGRO-ONION-C2 | Onion 은 Hexagonal/Ports & Adapters 의 대안으로 사용 가능하며 backend 비즈니스 어플리케이션에 주로 사용됨 | [§Comparison] "It can be successfully used as an alternative to a popular Hexagonal / Ports and Adapters architecture, and as such is predominantly used in the backend, business applications and services." | company-case-study |
backend 비즈니스 어플리케이션 | Onion 이 Hexagonal 보다 우월하다는 뜻 아님 — 저자는 두 스타일을 alternative 로 표현 |
| ALLEGRO-ONION-C3 | Onion 과 Hexagonal 의 주된 차이는 Onion 이 코드 레이아웃에 대해 더 구조화된 접근을 제공한다는 점 | [§Comparison] "The main difference I've found in the implementations of Hexagonal Architecture and Onion Architecture lies mostly in the overall, more structured approach to the code layout of the latter." | company-case-study |
코드 레이아웃 의사 결정 | 저자 1인의 견해 ("I've found") — 업계 합의가 아님 |
| ALLEGRO-ONION-C4 | Onion 은 3 layer 구조 (domain / application / infrastructure) 를 가짐 | [§Layer Structure] "There are three main layers in Onion Architecture: The domain layer, The application layer, The infrastructure layer each of which has its responsibilities." | company-case-study |
layer-first 패키지 구조 설계 | 일부 다른 Onion 해석은 4 layer (domain model / domain services / application / infrastructure) 를 가짐 — 본 자료는 3 layer 변형 |
| ALLEGRO-ONION-C5 | 의존성 방향은 항상 outside → inside, 외부 layer 는 모든 내부 layer 의 클래스를 볼 수 있음 (인접 layer 만이 아님) | [§Dependency Direction] "Every outer layer sees classes from all inner layers, not only the one directly below. Moreover, the dependency direction always goes from the outside to the inside, never the other way around." | company-case-study |
Onion 의 의존성 규칙 ArchUnit 변환 시 | 이 규칙이 "엄격한 layer architecture" 보다 완화된 형태 — 인접 layer 만 허용하는 strict layered 와 다름 |
Usage Boundaries / 적용 경계
- 이 자료가 직접 증명하는 것:
ALLEGRO-ONION-C1~C5: Allegro 엔지니어의 Onion 정의, Hexagonal 과의 비교, 3 layer 구조, 의존성 방향 규칙
- 이 자료가 증명하지 않는 것:
- Allegro 가 prod 에서 Onion 을 채택했다는 사실 — 본문은 해설 글로, 채택 사례 numeric metrics 없음
- Onion 이 Hexagonal/Clean 대비 운영 성능 / 개발 속도에서 우월하다는 정량 비교
- 본 글의 3 layer 가 Palermo 원본 Onion 의 정통 해석이라는 권위 — 저자 개인의 표현
- 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- ca-tmpl 의 4 layer (presentation / application / domain / infrastructure) 와 Allegro 의 3 layer (domain / application / infrastructure) 차이가 실제 운영에 미치는 영향
- "outside → inside, 모든 내부 layer 접근 가능" 규칙을 ArchUnit 으로 표현 시의 정확한 룰 (인접 layer 한정 vs 모든 내부 layer 허용)
메모 / Notes
- 적용 시나리오: Hexagonal 보다 layer 가 명시적인 가이드가 필요한 팀. 신규 개발자 온보딩 비용 절감이 중요할 때.
- 장점: layer 이름이 직관적 (domain/application/infrastructure) → ca-tmpl 의 4-layer 와 거의 동일한 어휘.
- 단점: layer 안에서 feature 를 어떻게 자를지는 본문에서 가이드 없음. 도메인 폭증 시 같은 문제 발생.
- ca-tmpl(feature-first) 와의 차이: Allegro 사례는 layer 최상위 + feature 분할 가이드 없음. ca-tmpl 의 4-layer 이름 (presentation/application/domain/infrastructure) 이 Onion 의 어휘를 차용한 것으로 보일 만큼 유사하나, 분할 우선순위가 정반대 — Onion 은 layer 우선, ca-tmpl 은 feature 우선.
- 신뢰도:
company-tech-blog/company-case-study— Allegro 1명 저자의 사례/해설로만 인용. "Onion 표준" 이라 부르지 않음.
Related / 관련
- 같은 주제 다른 raw:
- 인용하는 branch:
- 인용하는 project:
- 대안 그룹: Topic 1 — Architecture Layout (대안 5종: feature-first / layer-first / hexagonal / modulith / onion) — 본 자료는 대안 4 (onion)
- 인용한 wiki 요약: (미작성)