108 lines
8.5 KiB
Markdown
108 lines
8.5 KiB
Markdown
---
|
|
title: kamilmazurek/layered-architecture-template (GitHub) — Java/Spring Boot layer-first 구현 사례
|
|
source_type: company-tech-blog
|
|
url: https://github.com/kamilmazurek/layered-architecture-template
|
|
archive_url:
|
|
related_branches: [feature-architecture-enforcement-rules, feature-skeleton-package-blueprint-contract, feature-domain-feature-onboarding-contract]
|
|
related_projects: [ca-skeleton-operational-contract]
|
|
tags: [ca-architecture-layout, layer-first, github-template, spring-boot]
|
|
status: raw
|
|
confidence: low
|
|
created: 2026-05-22
|
|
last_reviewed: 2026-05-27
|
|
---
|
|
|
|
# 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}`.
|
|
|
|
## Related / 관련
|
|
|
|
- 같은 주제 다른 raw: (미수집 — bezkoder/spring-boot-three-layer 후보)
|
|
- 인용하는 branch:
|
|
- [[raw/branch-notes/feature-architecture-enforcement-rules]]
|
|
- [[raw/branch-notes/feature-skeleton-package-blueprint-contract]]
|
|
- [[raw/branch-notes/feature-domain-feature-onboarding-contract]]
|
|
- 인용하는 project:
|
|
- [[raw/project-notes/ca-skeleton-operational-contract]] (§19, §20)
|
|
- 인용한 wiki 요약: (미작성)
|