87 lines
5.7 KiB
Markdown
87 lines
5.7 KiB
Markdown
---
|
|
title: blog-topic / clean-architecture-reference-project-adoption
|
|
source_type: blog-topic
|
|
status: raw
|
|
related_branches: [feature-sample-removal-adoption-contract]
|
|
related_projects: [ca-tmpl]
|
|
tags: [blog-topic, ca-tmpl, architecture, testing, clean-architecture, ddd, api-contract]
|
|
created: 2026-06-17
|
|
status_label: ready-for-canonical
|
|
target_audience: backend-engineer
|
|
inspiration_url:
|
|
archive_url:
|
|
---
|
|
|
|
# blog-topic: clean-architecture-reference-project-adoption
|
|
|
|
> Layer: `raw/blog-topics/` — 채용공고가 아닌 작업·학습·트러블슈팅에서 나온 블로그 글감 원석. canonical 정제 전 raw 후보이며, 바로 `wiki/blog/` 로 승격하지 않는다.
|
|
|
|
## Parent / 부모
|
|
|
|
- [[raw/branch-notes/feature-sample-removal-adoption-contract]] — 레퍼런스 프로젝트 비교와 sample/adoption 계약 정리 과정에서 나온 글감.
|
|
|
|
## 트리거 / Trigger
|
|
|
|
- 트리거 유형: `branch-work`
|
|
- 트리거 날짜: 2026-06-17
|
|
- 트리거 연결 노트: [[raw/branch-notes/feature-sample-removal-adoption-contract]]
|
|
|
|
## 글감 / Topic seed
|
|
|
|
- 한 문장 요지: Clean Architecture 스켈레톤을 고도화할 때 레퍼런스 프로젝트를 그대로 베끼지 않고, 계약 검증·event reliability·bounded context·도메인 모델링·운영 도구로 분해해 흡수하는 방법.
|
|
- 예상 제목 후보:
|
|
- Clean Architecture 템플릿을 레퍼런스 프로젝트로 고도화하는 법
|
|
- 여러 DDD/Hexagonal 프로젝트에서 스켈레톤에 흡수할 것과 버릴 것
|
|
|
|
## 핵심 주장 후보 / Claim candidates
|
|
|
|
- 사실 후보:
|
|
- ca-tmpl 은 현재 module dependency gate, outbox relay, OpenAPI snapshot, env/one-type verification, runbook/registry 기반 운영 계약을 이미 갖고 있다. — 근거 후보: [[raw/branch-notes/feature-sample-removal-adoption-contract]], `docs/superpowers/plans/2026-06-17-reference-project-adoption.md`
|
|
- 조사 대상 레퍼런스들은 contract verification, acceptance-test, saga/outbox/inbox, modular monolith, domain modeling, observability, generator 측면에서 서로 다른 강점을 갖는다. — 근거 후보: [[raw/branch-notes/feature-sample-removal-adoption-contract]]
|
|
- 경험 후보:
|
|
- 로컬 README/구조/대표 구현을 evidence matrix 로 나누고, 그대로 흡수 금지 항목을 별도 표로 분리했다. — 근거 후보: [[raw/branch-notes/feature-sample-removal-adoption-contract]]
|
|
- 의견/해석 후보:
|
|
- 스켈레톤 프로젝트는 기능을 많이 담는 것보다, 새 프로젝트가 안전하게 확장할 수 있는 검증 가능한 seam 을 제공하는 편이 실무에 더 가깝다.
|
|
|
|
## Outline seed
|
|
|
|
1. 레퍼런스 프로젝트를 그대로 복제하면 생기는 문제 — stack drift, layer rule 충돌, sample 과 production 의 혼동을 설명한다.
|
|
2. 흡수 후보를 기능 축으로 재분류하기 — contract, event reliability, bounded context, domain modeling, ops/tooling 으로 나눈다.
|
|
3. ca-tmpl 에 먼저 적용할 P0 — contract verification, acceptance-test module, consumer inbox/dedupe 가 왜 가장 효과적인지 정리한다.
|
|
4. 보류해야 할 것들 — Spring Modulith, WebFlux, chaos, generator 는 optional spike 로 두는 이유를 적는다.
|
|
|
|
## Canonical 전환 후보 / Canonical extraction candidates
|
|
|
|
- `wiki/projects/ca-tmpl/reference-project-adoption.md` 후보:
|
|
- ca-tmpl 에 실제로 적용한 레퍼런스 흡수 전략과 검증 결과.
|
|
- `wiki/concepts/clean-architecture-template-evolution.md` 후보:
|
|
- Clean Architecture 템플릿을 진화시킬 때 레퍼런스를 평가하는 일반 기준.
|
|
- 필요한 추가 검증:
|
|
- Phase 1~2 구현 후 실제 테스트/빌드 결과.
|
|
- Spring Cloud Contract, Springwolf, Spring Modulith 의 ca-tmpl 현재 스택 호환성.
|
|
|
|
## Sources / 근거 후보
|
|
|
|
- [[raw/branch-notes/feature-sample-removal-adoption-contract]] — 레퍼런스 흡수와 sample/adoption 계약 정리 방향.
|
|
- `docs/superpowers/plans/2026-06-17-reference-project-adoption.md` — 레퍼런스 프로젝트 evidence matrix 와 적용 plan.
|
|
|
|
## 미해결 / Unknown
|
|
|
|
- 아직 확인해야 할 사실: 각 P0/P1 항목은 구현 전 focused audit 과 dependency compatibility 확인이 필요하다.
|
|
- 과장하면 안 되는 부분: 현재 상태는 `documented-only` 계획이며, contract/inbox/acceptance-test 구현이 완료된 것이 아니다.
|
|
- 블로그로 쓰기 전에 필요한 canonical 정제: 실제 Phase 1 또는 Phase 2 구현 결과와 검증 로그를 `wiki/projects/ca-tmpl/...` 로 승격해야 한다.
|
|
|
|
## Decision / 처리 결정
|
|
|
|
- 액션: `promote-to-canonical`
|
|
- 이유: `wiki/projects/ca-tmpl/sample-fixture-and-adoption.md` 에 reference project adoption / sample-adoption 전략 글감으로 반영한다.
|
|
- 다음 단계: 정확성 감사에서 발견된 결함을 반영한 계획만 blogify 근거로 사용한다.
|
|
|
|
## Related / 관련
|
|
|
|
- 관련 branch: [[raw/branch-notes/feature-sample-removal-adoption-contract]]
|
|
- 관련 error: 없음
|
|
- 관련 interview prep: 없음
|
|
- derived blog: 생성 전. 생성 시 `wiki/blog/clean-architecture-reference-project-adoption-2026-06-17.md` 후보
|
|
- 정확성 감사 (2026-06-19): 이 글감의 근거가 된 계획 문서의 README 라인 인용/장점 요약을 19개 원본 프로젝트와 대조한 결과 — 13개 정확, 6개 결함(library "domain/integration event 구분"은 미구현 placeholder인 phantom 장점; dddsample-core/food-ordering는 장점 실재하나 인용 라인 오류; 라인-정밀도 결함 묶음). 산출물: `ca-tmpl/docs/superpowers/specs/2026-06-19-reference-project-adoption-accuracy-report.md`. **블로그로 승격 시 위 결함이 수정된 계획을 근거로 삼을 것** — 미수정 인용을 그대로 인용하면 글의 사실성이 깨진다.
|