Files

T

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

title, source_type, status, related_branches, related_projects, tags, created, status_label, target_audience, inspiration_url, archive_url

title

source_type

status

related_branches

related_projects

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 계약 정리 과정에서 나온 글감.

한 문장 요지: Clean Architecture 스켈레톤을 고도화할 때 레퍼런스 프로젝트를 그대로 베끼지 않고, 계약 검증·event reliability·bounded context·도메인 모델링·운영 도구로 분해해 흡수하는 방법.
예상 제목 후보:
- Clean Architecture 템플릿을 레퍼런스 프로젝트로 고도화하는 법
- 여러 DDD/Hexagonal 프로젝트에서 스켈레톤에 흡수할 것과 버릴 것

사실 후보:
- 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 을 제공하는 편이 실무에 더 가깝다.

레퍼런스 프로젝트를 그대로 복제하면 생기는 문제 — stack drift, layer rule 충돌, sample 과 production 의 혼동을 설명한다.
흡수 후보를 기능 축으로 재분류하기 — contract, event reliability, bounded context, domain modeling, ops/tooling 으로 나눈다.
ca-tmpl 에 먼저 적용할 P0 — contract verification, acceptance-test module, consumer inbox/dedupe 가 왜 가장 효과적인지 정리한다.
보류해야 할 것들 — Spring Modulith, WebFlux, chaos, generator 는 optional spike 로 두는 이유를 적는다.

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 현재 스택 호환성.

raw/branch-notes/feature-sample-removal-adoption-contract — 레퍼런스 흡수와 sample/adoption 계약 정리 방향.
docs/superpowers/plans/2026-06-17-reference-project-adoption.md — 레퍼런스 프로젝트 evidence matrix 와 적용 plan.

아직 확인해야 할 사실: 각 P0/P1 항목은 구현 전 focused audit 과 dependency compatibility 확인이 필요하다.
과장하면 안 되는 부분: 현재 상태는 documented-only 계획이며, contract/inbox/acceptance-test 구현이 완료된 것이 아니다.
블로그로 쓰기 전에 필요한 canonical 정제: 실제 Phase 1 또는 Phase 2 구현 결과와 검증 로그를 wiki/projects/ca-tmpl/... 로 승격해야 한다.

액션: promote-to-canonical
이유: wiki/projects/ca-tmpl/sample-fixture-and-adoption.md 에 reference project adoption / sample-adoption 전략 글감으로 반영한다.
다음 단계: 정확성 감사에서 발견된 결함을 반영한 계획만 blogify 근거로 사용한다.

관련 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. 블로그로 승격 시 위 결함이 수정된 계획을 근거로 삼을 것 — 미수정 인용을 그대로 인용하면 글의 사실성이 깨진다.