llm-wiki/raw/official-docs/layer-first-baeldung-clean-architecture-spring-boot.md

---
title: Clean Architecture with Spring Boot (Baeldung)
source_type: personal-blog
status: needs-confirmation
confidence: low
url: https://www.baeldung.com/spring-boot-clean-architecture
archive_url:
tags: [ca-architecture-layout, layer-first, clean-architecture, spring-boot]
related_branches: [feature-architecture-enforcement-rules, feature-skeleton-package-blueprint-contract, feature-domain-feature-onboarding-contract]
related_projects: [ca-skeleton-operational-contract]
created: 2026-05-22
last_reviewed: 2026-05-27
---

# Clean Architecture with Spring Boot (Baeldung)

> Layer: `raw/official-docs/` (분류상 — 폴더 위치). **실제 source_type 은 `personal-blog`** (Baeldung 은 공식 벤더 doc 아님). ca-tmpl 의 feature-first 결정 대비 **대안 2 layer-first** 의 대표 튜토리얼.

## Parent / 활용 branch (필수)

| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| [[raw/branch-notes/feature-architecture-enforcement-rules]] | layer-first 대안이 어떻게 보이는지 비교 baseline — feature-first 채택의 trade-off 평가 |
| [[raw/branch-notes/feature-skeleton-package-blueprint-contract]] | "최상위 패키지 = 레이어" 모델의 실패 모드 (도메인 늘어날 때 cohesion 저하) 사례 보관 |
| [[raw/branch-notes/feature-domain-feature-onboarding-contract]] | 신규 도메인 추가 시 layer-first 가 왜 reject 되는지의 비교 근거 |

## 컨텍스트 / 왜 저장했는지

ca-tmpl의 feature-first 결정에 대한 대안 2: Layer-first (전통 3-layer + Clean Architecture 레이어링)의 대표적 튜토리얼. 한국/글로벌 신입~3년차 백엔드가 가장 먼저 접하는 패키지 구조의 reference.

## 출처 / Source

- 원본 URL: https://www.baeldung.com/spring-boot-clean-architecture
- 아카이브 URL: (미확보 — WebFetch 시 baeldung.com 403 Forbidden, web.archive.org 도 본 환경에서 fetch 불가)
- 저자/조직: Baeldung (Spring 학습 블로그, 검색 노출 1군이지만 공식 문서는 아님)
- 발행일: (지속 업데이트되는 튜토리얼 페이지)
- 마지막 확인일: 2026-05-27 (URL 접근 불가 — 본 raw 의 인용은 검색 스니펫 기반, verbatim PDF 미확보)

## 핵심 인용 / Key quotes

> **WARNING**: 다음 인용은 **검색 스니펫 / 간접 요약** 이며 baeldung.com 원본 페이지에서 verbatim 추출되지 않았다. 본 환경에서 baeldung.com 은 403 Forbidden 으로 fetch 불가. 모든 quote 는 `needs-confirmation`.

> [§검색 스니펫, paraphrased] "Clean architecture creates a user registration API following Robert C. Martin's Clean Architecture with entities, use cases, interface adapters, and frameworks/drivers layers."

> [§구조 요약, paraphrased] 패키지를 `entities`, `usecases`, `adapters`, `frameworks`처럼 layer 단위로 잘라 두고 그 안에 도메인 클래스를 배치하는 구성.

(원문 본문에서 직접 인용 추출은 미완. 추가 검증 필요 — 전체 문서 status `needs-confirmation`.)

## Claims Extracted / 추출된 주장

| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| BAELDUNG-CA-C1 | baeldung.com/spring-boot-clean-architecture 페이지가 Spring Boot 에 Clean Architecture (Robert C. Martin 의 entities / use cases / interface adapters / frameworks-drivers 4 layer) 를 적용하는 튜토리얼로 존재 | [§검색 스니펫] "Clean architecture creates a user registration API following Robert C. Martin's Clean Architecture with entities, use cases, interface adapters, and frameworks/drivers layers." | `needs-confirmation` (verbatim 미확보) | Spring Boot 학습자 대상 튜토리얼 reference | 본 페이지가 ca-tmpl 의 feature-first 대안인 layer-first 의 "최선의" 예시라는 뜻은 아님 — 단지 가장 자주 검색 노출되는 튜토리얼 |
| BAELDUNG-CA-C2 | 페이지는 패키지를 `entities` / `usecases` / `adapters` / `frameworks` 같은 **레이어 이름** 으로 최상위 분할하여 배치하는 구성을 제시 | [§구조 요약, paraphrased] "패키지를 `entities`, `usecases`, `adapters`, `frameworks`처럼 layer 단위로 잘라" | `needs-confirmation` (paraphrased) | layer-first 패키지 구조 사례 분석 | 동일 페이지가 feature 분할을 함께 권장하는지 여부는 본 자료로 확인 불가 (원본 미접근) |
| BAELDUNG-CA-C3 | Baeldung 은 공식 벤더 doc 이 아닌 개인/팀 운영 학습 블로그이며, 본 글의 권고는 best practice 가 아니라 학습용 가이드 | (Baeldung 자체 메타 정보 — 운영 주체 = Eugen Paraschiv 의 회사, 공식 Spring/Pivotal 산하 아님) | `tutorial` | 공식 best practice 판단 시 인용 금지 기준 | "Baeldung 의 모든 글이 부정확" 이라는 뜻은 아님 — 단지 공식 표준 인증 아님 |

## Usage Boundaries / 적용 경계

- **이 자료가 직접 증명하는 것** (현 상태):
  - `BAELDUNG-CA-C3`: Baeldung 자체가 personal/team blog 라는 메타 사실
- **이 자료가 증명하지 않는 것** (verbatim 미확보):
  - `BAELDUNG-CA-C1`, `C2`: 페이지 본문의 정확한 wording — 검색 스니펫에 의존, 원문 직접 확인 필요
  - "layer-first 가 항상 cohesion 저하를 일으킨다" 같은 일반화 — 본 글 자체는 사례, Sahibinden 글 / 별도 측정 결합 필요
  - ca-tmpl 이 layer-first 를 거부한 결정의 정량 근거 — 본 자료는 비교 baseline 일 뿐
- **내 프로젝트에 적용하려면 추가 확인이 필요한 것**:
  - 본 raw 의 status 를 `needs-confirmation` 에서 풀려면: baeldung.com 본문에 직접 접속 + verbatim 5문장 추출 + Strength 재평가 (`tutorial` 유지)
  - layer-first 의 "low cohesion" 문제가 실제로 어느 규모부터 (feature 수) 나타나는지 — 본 글 범위 밖

## 메모 / Notes (내 프로젝트 해석 — 자료 직접 인용 아님)

- 적용 시나리오: 학습용 튜토리얼, 작은 단일 도메인 서비스.
- 장점: Robert C. Martin의 layer 정의(Entities / Use Cases / Interface Adapters / Frameworks)와 1:1로 매핑됨. 입문자가 책 → 코드를 연결하기 쉬움.
- 단점: 도메인이 여러 개일 때 모든 `usecases`가 한 패키지에 몰림 → Sahibinden 글이 지적한 "low cohesion within packages" 문제 발생.
- ca-tmpl(feature-first)와의 차이: ca-tmpl은 동일한 4-layer 이름(presentation/application/domain/infrastructure)을 쓰되, 최상위 분할을 **feature** 로 둠. Baeldung 튜토리얼은 최상위 분할이 **layer**.
- 신뢰도: `personal-blog` 등급 (Baeldung 의 운영 주체는 Eugen Paraschiv 의 회사 — Spring/Pivotal 공식 아님). 공식 best practice로 인용 금지. Strength = `tutorial` 또는 `engineering-blog`.

## 관련 ca-tmpl branch / contract

- 적용 branch-note:
  - [[raw/branch-notes/feature-architecture-enforcement-rules]]
  - [[raw/branch-notes/feature-skeleton-package-blueprint-contract]]
  - [[raw/branch-notes/feature-domain-feature-onboarding-contract]]
- canonical contract 섹션:
  - [[raw/project-notes/ca-skeleton-operational-contract#20. Skeleton Blueprint Contract]]
  - [[raw/project-notes/ca-skeleton-operational-contract#19. Domain Application Readiness Contract]]
- 대안 그룹: **Topic 1 — Architecture Layout** (대안 5종: feature-first / layer-first / hexagonal / modulith / onion)
- 본 source의 위치: 대안 1: layer-first

## Related / 관련

- 같은 주제 다른 official-doc / company-tech-blog:
  - [[raw/official-docs/feature-first-uncle-bob-screaming-architecture-2011]] (feature-first 측 baseline)
  - [[raw/company-tech-blogs/feature-first-sahibinden-package-by-layer-vs-feature]] (layer-first 의 단점을 사례로 진단)
- 인용하는 branch:
  - [[raw/branch-notes/feature-architecture-enforcement-rules]]
- 인용하는 wiki: (미작성)