Files

T

DongHyeonka d71669eb59 fix: 하네스 제거 및 keycloak 문서 보강

2026-07-25 12:53:13 +09:00

8.5 KiB

Raw Permalink Blame History

title, source_type, url, archive_url, related_branches, related_projects, tags, status, confidence, created, last_reviewed

title

source_type

url

archive_url

related_branches

related_projects

kamilmazurek/layered-architecture-template

Layer: raw/company-tech-blogs/ — 개인 GitHub template README verbatim. Spring Boot 환경의 layer-first 4-layer (API/Service/Repository/Database) 구조 예시. 주의: 본 자료는 개인 GitHub repository (star 수 낮음) 이므로 strength = engineering-blog. 공식 best practice 로 인용 금지. 분류 메모: 본 카테고리 company-tech-blog 는 묶음. 본 자료의 정확한 분류는 personal-blog 에 가깝지만 현재 raw 디렉토리 구조가 raw/personal-blogs/ 를 갖지 않아 가장 가까운 카테고리에 보존. 후속 정리 시 재분류 검토.

Parent / 활용 branch (필수)

Branch	이 자료가 정당화하는 결정
raw/branch-notes/feature-architecture-enforcement-rules	feature-first vs layer-first 비교 시 layer-first 의 구체 구현 예시 (대안 비교 매트릭스 입력)
raw/branch-notes/feature-skeleton-package-blueprint-contract	skeleton package blueprint 결정 시 4-layer 이름은 동일하나 최상위 분할이 반대인 layer-first 의 사례
raw/branch-notes/feature-domain-feature-onboarding-contract	새 도메인 추가 시 layer-first 가 디렉토리 비대화로 이어지는 한계 비교
raw/project-notes/ca-skeleton-operational-contract	§19, §20 — Skeleton Blueprint Contract / Domain Application Readiness Contract 의 layer-first 대안 reference

컨텍스트 / 왜 저장했는지

ca-tmpl의 feature-first 결정에 대한 대안 2: Layer-first 구조를 그대로 구현한 GitHub template. 별 1000+ 후보(bezkoder/spring-boot-three-layer 류)는 직접 본문 확인 어려움 — 동일 구조를 가진 template로 대체. Java 21 + Spring Boot 최신 스택에서의 전형적 layered 패키지 구조를 보존.

출처 / Source

원본 URL: https://github.com/kamilmazurek/layered-architecture-template
아카이브 URL: (미수집)
저자 / 조직: Kamil Mazurek (개인)
발행일: rolling (지속 유지보수)
마지막 확인일: 2026-05-27
Star 수: 소규모 reference (개인 template)

핵심 인용 / Key quotes (verbatim)

[§README intro] "This repository contains a Spring Boot microservice template that follows a modern REST-based Layered Architecture approach."

[§README intro] "a Spring Boot microservice template that follows a clean layered architecture. It offers modular REST API with a clear separation of concerns"

[§Layers — API Layer] "API Layer: Exposes REST endpoints and handles HTTP requests/responses (equivalent to Presentation)."

[§Layers — Service Layer] "Service Layer: Implements business logic and orchestrates operations (equivalent to Business Logic)."

[§Layers — Repository Layer] "Repository Layer: Interfaces with the database, handling CRUD operations (equivalent to Persistence)."

[§Layers — Database Layer] "Database Layer: Stores the application data."

[§Benefits — Simplicity] "Simplicity and Familiarity: Widely adopted, this pattern is easy to understand and implement"

[§Benefits — Separation] "Separation of Responsibilities: The architecture organizes code into layers like controller, service, and repository, each handling its role clearly."

[§Benefits — Maintainability] "Maintainability: Encapsulation of responsibilities within layers makes the application easier to debug, extend, and refactor"

[§Benefits — Testability] "Testability: With clearly defined boundaries between layers, unit and integration testing become more straightforward"

[§Benefits — Scalability] "Scalability for Simple Use Cases: Good fit for CRUD or moderate business logic apps, as layers support growth"

Claims Extracted / 추출된 주장

Claim ID	Claim (이 자료가 직접 말하는 것)	Evidence quote	Strength	Applies to	Does not prove
LAYER-FIRST-TMPL-C1	본 template 는 Spring Boot 마이크로서비스 + REST 기반 layered architecture 접근법을 따름	[§README intro] "This repository contains a Spring Boot microservice template that follows a modern REST-based Layered Architecture approach."	`engineering-blog`	Spring Boot REST API 마이크로서비스 reference	본 template 의 구조가 모든 Spring Boot 프로젝트의 best practice 라는 뜻은 아님 — 개인 template, star 수 낮음
LAYER-FIRST-TMPL-C2	layered 구조의 4 layer 는 API / Service / Repository / Database 로 분할되며 각각 REST endpoint / 비즈니스 로직 / DB CRUD / 데이터 저장 책임	[§Layers — API/Service/Repository/Database Layer] (4개 verbatim 인용 위 참조)	`engineering-blog`	단일 도메인 CRUD API 의 layer-first 구조	4-layer 외 다른 분할 (예: hexagonal 의 port/adapter, modulith 의 module) 이 invalid 라는 뜻은 아님
LAYER-FIRST-TMPL-C3	layer-first 의 장점은 (1) Simplicity & Familiarity (2) Separation of Responsibilities (3) Maintainability (4) Testability (5) Scalability for Simple Use Cases	[§Benefits — 5개 항목] (5개 verbatim 인용 위 참조)	`engineering-blog`	학습용 / 단일 도메인 microservice / MVP 시 layer-first 채택 시	본 인용은 self-attestation (template 저자 자체 평가). 대형 도메인에서의 단점 (cross-cutting concern, 패키지 비대화) 은 본 인용에 없음
LAYER-FIRST-TMPL-C4	(부재) layer-first 가 도메인 증가 시 디렉토리 비대화 / cross-cutting concern 분산 / feature 단위 응집도 저하 같은 단점을 갖는다는 진술은 본 인용 범위 내에 명시 없음	(부재 자체가 claim — self-marketing 한계)	`needs-confirmation`	layer-first 의 한계 비교	메모 섹션의 단점 진술은 본 자료 외 다른 근거 필요 (예: Vaughn Vernon "Implementing DDD", Sam Newman "Building Microservices")

Usage Boundaries / 적용 경계

이 자료가 직접 증명하는 것:
- LAYER-FIRST-TMPL-C1, C2, C3: Spring Boot layer-first 구조의 한 구체 구현 예시 + 저자가 명시한 장점 5개
이 자료가 증명하지 않는 것:
- LAYER-FIRST-TMPL-C4: layer-first 의 단점 (도메인 증가 시 패키지 비대화 등)
- layer-first vs feature-first 의 일반적 우위 비교
- 본 template 가 production 에서 검증되었다는 사실 (star 수 낮음, 개인 reference)
내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- ca-tmpl 의 features/{name}/{presentation,application,domain,infrastructure} 구조와의 정량 비교 (NRR, ArchUnit rule 수 등)
- 도메인 5+ 추가 시 layer-first 의 cross-cutting concern (transaction, security) 분산 사례
- 본 template 외 star 수 높은 layer-first reference (bezkoder/spring-boot-three-layer 등) 의 추가 수집

메모 / Notes (내 프로젝트 해석)

검증되지 않은 내 추론은 여기에 두지 말 것 — wiki source-summary 단계에서.

적용 시나리오: 단일 도메인 microservice, MVP, 학습용.
장점: 새 팀원이 5초 만에 구조 파악. controller → service → repository 흐름이 디렉터리 트리에 그대로 드러남.
단점: 별 수에서 보이듯 reference로서의 권위는 약함. 도메인이 늘면 패키지가 비대해짐.
ca-tmpl(feature-first)와의 차이: 동일한 4-layer 이름을 쓰되 최상위 분할이 반대. 이 template은 api/, service/, repository/가 최상위. ca-tmpl은 features/{name}/{presentation,application,domain,infrastructure}.

같은 주제 다른 raw: (미수집 — bezkoder/spring-boot-three-layer 후보)
인용하는 branch:
인용하는 project:
- raw/project-notes/ca-skeleton-operational-contract (§19, §20)
인용한 wiki 요약: (미작성)

8.5 KiB Raw Permalink Blame History