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 | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Hexagonal Architecture (Ports and Adapters) — Cockburn 정리 (Wikipedia) | official-doc | https://en.wikipedia.org/wiki/Hexagonal_architecture_(software) | raw | high |
|
|
|
2026-05-22 | 2026-05-27 |
Hexagonal Architecture (Ports and Adapters) — Cockburn 정리 (Wikipedia)
Layer:
raw/official-docs/— Wikipedia "Hexagonal architecture (software)" 항목의 원문 발췌. Cockburn 원형 글(alistair.cockburn.us/hexagonal-architecture/)은 2026-05 시점 SSL 인증서 만료로 직접 페치 실패 → Wikipedia 정리본을 1차 근거로 사용. ca-tmplTopic 1 — Architecture Layout의 대안 비교 (대안 2: hexagonal) baseline.
Parent / 활용 branch (필수)
이 자료는 혼자 존재하지 않는다. ca-tmpl architecture 결정 비교군의 한 축.
| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| raw/branch-notes/feature-architecture-enforcement-rules | ArchUnit/Modulith 등 의존성 enforcement 도입 시 Hexagonal "안/밖" 분리가 enforcement 단위로 적합한지 비교 baseline |
| raw/branch-notes/feature-skeleton-package-blueprint-contract | feature-first vs hexagonal port/adapter 분리 — ca-tmpl 패키지 blueprint 의 비교 대안 (대안 2: hexagonal) |
| raw/branch-notes/feature-domain-feature-onboarding-contract | 새 feature 추가 시 port/adapter 정의 워크플로우 vs ca-tmpl feature-first 워크플로우 비교 근거 |
특정 branch 없이 foundational 조사로 수집한 경우:
- raw/project-notes/ca-skeleton-operational-contract — §20 Skeleton Blueprint Contract / §19 Domain Application Readiness Contract 의 대안 비교 (대안 2: hexagonal)
컨텍스트
ca-tmpl 의 feature-first 결정에 대한 대안 3: Hexagonal (Ports & Adapters) 원형. ca-tmpl 이 feature 내부에서 4-layer 를 쓰는 것과 비교할 baseline. Hexagonal 은 layer 대신 "안(application core) vs 밖(adapters)" 이분법.
출처 / Source
- 원본 URL (개념 정리): https://en.wikipedia.org/wiki/Hexagonal_architecture_(software)
- 원형 글 URL: https://alistair.cockburn.us/hexagonal-architecture/ (2026-05 시점 SSL 인증서 만료로 직접 페치 실패 — 별도 검증 필요)
- 아카이브 URL: (미수집)
- 저자 / 조직: Alistair Cockburn (원형 1994, 공식 "Ports and Adapters" 재명명 2005). Wikipedia 항목은 communal 편집.
- 발행일: Wikipedia 항목 rolling docs; 원형 글 2005-09-04
- 마지막 확인일: 2026-05-27
- 재검증 상태 (2026-05-27): WebFetch 로 Wikipedia 페이지 재확인 완료 — 5/5 핵심 인용 verbatim 일치. 원형 Cockburn 페이지(alistair.cockburn.us) 는 SSL 인증서 만료로 별도 검증 미수행 (Wikipedia 정리본으로 corroborate).
핵심 인용 / Key quotes (verbatim)
[§Lead] "It aims at creating loosely coupled application components that can be easily connected to their software environment by means of ports and adapters."
[§History] "in 2005 Cockburn renamed it 'Ports and adapters'."
[§Why six borders] "The purpose was not to suggest that there would be six borders/ports, but to leave enough space to represent the different interfaces needed between the component and the external world."
[§Structure] "The hexagonal architecture divides a system into several loosely-coupled interchangeable components, such as the application core, the database, the user interface, test scripts and interfaces with other systems."
[§Adapters] "Adapters are the glue between components and the outside world. They tailor the exchanges between the external world and the ports that represent the requirements of the inside of the application component."
Claims Extracted / 추출된 주장
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| HEX-WIKI-C1 | Hexagonal architecture 의 목적은 loosely coupled application components 가 ports/adapters 를 통해 소프트웨어 환경에 쉽게 연결되는 것 | [§Lead] "It aims at creating loosely coupled application components that can be easily connected to their software environment by means of ports and adapters." [2026-05-27 verified] | official-reference |
Hexagonal 패턴 일반 설명 | "loosely coupled" 의 정량 기준 (cyclomatic / fan-out) 은 본 인용에 없음 — 별도 metric 필요 |
| HEX-WIKI-C2 | Cockburn 이 2005년에 이 패턴을 "Ports and adapters" 로 재명명 | [§Origin] "in 2005 Cockburn renamed it 'Ports and adapters'." [2026-05-27 verified] | official-reference |
명칭의 역사적 사실 | 재명명의 이유 (혼동 회피 vs 명확화) 는 본 인용에 없음 |
| HEX-WIKI-C3 | 육각형 (hexagon) 의 6개 면은 "6개의 port 가 있어야 한다" 는 뜻이 아니며, 컴포넌트와 외부 세계 사이의 서로 다른 interface 들을 표현할 충분한 공간을 두기 위함 | [§Principle] "The purpose was not to suggest that there would be six borders/ports, but to leave enough space to represent the different interfaces needed between the component and the external world." [2026-05-27 verified] | official-reference |
다이어그램 표현 의도의 해석 | port 개수 제약이 없다는 뜻 — 즉 port 가 6개를 초과해도 문제없다는 것은 별도 추론 (다이어그램 컨벤션과 구현 컨벤션 분리) |
| HEX-WIKI-C4 | Hexagonal 은 시스템을 application core, database, user interface, test scripts, 외부 시스템 interface 등 여러 loosely-coupled interchangeable component 로 분할 | [§Principle] "The hexagonal architecture divides a system into several loosely-coupled interchangeable components, such as the application core, the database, the user interface, test scripts and interfaces with other systems." [2026-05-27 verified] | official-reference |
Hexagonal 의 컴포넌트 구성 | 각 컴포넌트가 정확히 어떻게 분리되어야 하는지 (모듈 vs 패키지 vs 서비스) 는 본 인용에 없음 |
| HEX-WIKI-C5 | Adapter 는 컴포넌트와 외부 세계 사이의 glue 이며, 외부 세계와 application 내부의 요구를 표현하는 port 사이의 교환을 tailor 함 | [§Principle] "Adapters are the glue between components and the outside world. They tailor the exchanges between the external world and the ports that represent the requirements of the inside of the application component." [2026-05-27 verified] | official-reference |
adapter 의 역할 정의 | adapter 구현이 framework 의존성을 가져도 되는지 / 어디까지 leak 이 허용되는지는 본 인용에 없음 |
Usage Boundaries / 적용 경계
- 이 자료가 직접 증명하는 것:
HEX-WIKI-C1~C5: Hexagonal 패턴의 목적, 역사적 명명, 다이어그램 의도, 컴포넌트 분할 사상, adapter 의 역할에 대한 Wikipedia 수준의 일반 정의
- 이 자료가 증명하지 않는 것:
- Cockburn 원형 글의 정확한 문장 (SSL 만료로 직접 접근 불가, Wikipedia 가 paraphrase 했을 가능성)
- "to allow an application to equally be driven by users, programs, automated test or batch scripts" 같은 driving/driven adapter 의 대칭성 강조 문장 — Wikipedia 정리본 인용 범위 밖
- port/adapter 가 어떤 언어/프레임워크에서 정확히 어떻게 구현되어야 하는지 (Java interface vs functional)
- "feature-first vs hexagonal" 비교에 대한 공식 입장 (Cockburn 원형은 feature 개념 없음)
- company-tech-blog 사례 (e.g., 우아한형제들 4-Hexagon) 가 Cockburn 의 official 의도라는 보장 — 별도 사례로 분리 평가 필요
- 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- Cockburn 원형 글의 4 tenets (driving/driven adapter 대칭, port-only public API 등) 의 verbatim 추출 (SSL 복구 또는 archive.org 스냅샷 확보 시)
- ca-tmpl 의 4-layer (presentation/application/domain/infrastructure) 가 hexagonal 의 "core vs adapter" 와 정확히 어떤 mapping 인지 (특히 application layer 의 위치)
- company-tech-blog 사례 (4-Hexagon outputPort 폭증 등) 는 vendor-specific 결정이며 Cockburn official 과 corroborate 되지 않음 → 본 official-doc 으로 corroborate 시 신중
메모 / Notes (내 프로젝트 해석)
본 섹션은 자료 직접 인용 아님. ca-tmpl 비교 컨텍스트 해석.
- 적용 시나리오: 외부 의존성(DB, 메시지 브로커, 외부 API) 이 많고 교체 가능성이 있는 시스템. 테스트 가능성이 핵심 KPI 일 때.
- 장점: 비즈니스 로직(코어) 이 인프라 변경에 영향받지 않음. driving/driven adapter 양방향 대칭이 명확.
- 단점: port 인터페이스 수가 폭증. 작은 서비스에는 과한 추상화.
- ca-tmpl(feature-first) 와의 차이: ca-tmpl 은 feature 를 최상위로 두고 그 안에 layer 4개. Hexagonal 원형은 "feature" 개념이 없고 application core 하나에 adapter 들을 붙임. ca-tmpl 은 hexagonal 의 "안/밖" 발상을 feature 안에 축소 복제한 하이브리드로 해석 가능 (미검증).
- 검증 필요: Cockburn 원문에서 "to allow an application to equally be driven by users, programs, automated test or batch scripts" 같은 intent 문장을 직접 인용 추출 필요 (SSL 만료로 미수행).
Related / 관련
- 같은 주제 다른 official-doc:
- raw/official-docs/hexagonal-thombergs-buckpal-github (Java/Spring reference 구현)
- raw/official-docs/onion-palermo-original-2008 (자주 혼동되는 Onion 원형)
- raw/official-docs/modulith-spring-official-doc (modular monolith 공식 대안)
- 같은 주제 company-tech-blog:
- raw/company-tech-blogs/hexagonal-woowahan-techblog-2023 (한국 대기업 실 적용 사례 — vendor-specific)
- 인용하는 branch / project:
- 인용한 wiki 요약: (미작성)