---
title: ca-tmpl - Sample Fixture & Adoption 결정
source_type: project
status: verified
confidence: high
tags: [ca-tmpl, sample-fixture, template, adoption, actually-implemented, locally-verified]
related_projects: [ca-tmpl]
last_reviewed: 2026-07-02
---

# ca-tmpl - Sample Fixture & Adoption 결정

> Layer: `wiki/projects/` — ca-tmpl 프로젝트 내 sample fixture / removal / adoption 결정 사실 기록. 일반 개념은 [[wiki/concepts/sample-fixture-and-adoption]].

## 프로젝트 컨텍스트

- **프로젝트**: ca-tmpl (clean architecture skeleton template repository).
- **범위**: skeleton 운영 계약(envelope / error / capability / transaction / idempotency)을 트리거하기 위한 **sample fixture** 정의와, 실제 도메인을 얹을 때 sample을 production runtime에서 비활성화하면서 운영 계약을 보존하는 **sample-off / adoption** 절차의 결정.
- **현황**: skeleton 설계 단계. canonical operational contract 문서 작성 진행 중.
  - sample-ticket 12 scenario matrix + 6-field minimum model + state machine + optimistic lock + idempotency key 결정 완료(문서).
  - sample-off profile + production dependency 차단 + dual-mode CI matrix (sample-on / sample-off 둘 다 release-blocking) + multi-module adoption checklist 결정 완료(문서).
  - **C2 구현 + 로컬 검증 완료.** `sample-portfolio` module, sample domain/use case/web/persistence tests, `sampleFixture` configuration, `sampleOffTest`, CI sample-off job이 존재한다. 실제 외부 프로젝트 adoption 사례는 없다.

## 실제 구현 내용 (`actually-implemented`)

- `sample-portfolio` module이 template fixture/reference로 유지된다.
- sample domain, use case, web controller, persistence adapter, OpenAPI snapshot, authz/idempotency/outbox 관련 sample tests가 존재한다.
- `app-bootstrap/build.gradle`에 `sampleFixture` configuration과 `sampleOffTest` task가 존재한다.
- `SampleRemovalSmokeContractTest`가 production dependency 차단, `sampleFixture` wiring, `sampleOffTest`, CI workflow sample-off command를 검증한다.
- `.github/workflows/ci-quality-gates.yml`에 `./gradlew :app-bootstrap:sampleOffTest`가 포함된다.

## 로컬/dev 검증 (`locally-verified`)

- `./gradlew check` 통과(2026-07-02, `BUILD SUCCESSFUL`, 114 tasks).
- `:app-bootstrap:sampleOffTest`, `checkstyleSampleOffTest`, `spotbugsSampleOffTest`가 check graph에 포함되어 실행되었다.
- `SampleRemovalSmokeContractTest`가 sample-off classpath에 `sample-portfolio` jar가 없는지 확인한다.

## 운영 검증 (`prod-verified`)

- 없음. ca-tmpl skeleton 자체가 운영 채택 사례가 없으며, sample-on / sample-off CI matrix가 release를 실제로 차단한 사례도 없다.

## 문서/계획만 존재 (`documented-only` / `planned`)

### Sample fixture 결정 (canonical §17, §22)

- **자체 fixture `sample-ticket` 채택.** 5종 대안(Spring Petclinic / RealWorld / Spring Cloud microservices sample / Stripe testmode / no fixture) 검토 후 선택. 근거는 contract 매트릭스 부재(Petclinic / RealWorld), 인프라 과도(Spring Cloud), 도메인 한정 SaaS sandbox(Stripe), 행위 검증 불가(no fixture).
- **sample-ticket 12 scenario matrix** (canonical §22): create / get / list / update / close / reopen / conflict (optimistic lock) / duplicate (idempotency) / not-found / validation-error / forbidden / transactional rollback 흐름. envelope / error code / capability gate / transaction boundary / idempotency key를 트리거하기 위한 시나리오 집합으로 정의.
- **6-field minimum model**: `TicketId`, `TicketTitle`, `TicketStatus`, `TicketVersion`, `TicketOwner`, `IdempotencyKey`. 비즈니스 기능이 아니라 contract trigger에 필요한 최소 필드만.
- **State machine**: `OPEN → IN_PROGRESS → CLOSED`. reopen은 `CLOSED → OPEN` 한정. 상태 전이 위반은 conflict 시나리오로 검증.
- **Optimistic lock**: `TicketVersion` 기반. 동일 ticket에 대한 동시 update에서 conflict scenario 발생.
- **Idempotency key**: `IdempotencyKey` 필드. 동일 key 재요청 시 동일 응답 보장 scenario.

### Sample-off / adoption 결정 (canonical §17, §29 G-H)

- **Sample-off first adoption**:
  1. Spring profile (`sample-off`)로 sample bean / route 제외.
  2. `sample-ticket` module은 template fixture/reference로 유지하되, production runtime/default profile과 새 도메인은 sample에 의존하지 않음.
  fork한 프로젝트에서 sample 코드를 정리하는 것은 선택 사항이며, ca-tmpl 기본 blueprint의 목표는 module 삭제가 아니라 runtime 노출 차단과 의존성 차단이다.
- **Dual-mode CI matrix**: `sample-on` / `sample-off` 두 mode를 **둘 다 release-blocking** 으로 운영. sample-off 상태에서도 envelope / capability / transaction / idempotency 계약이 그대로 유지되는지 회귀 검증.
- **Multi-module adoption checklist**: `feature-domain-feature-onboarding-contract`의 New Domain Module Slice + Read/Write Difference Table을 따른다. 핵심은 `domain-core`, `application-core`, `adapter-*`, `shared-contract`, `app-bootstrap` 경계에 새 도메인을 얹고 `sample-ticket` import 없이 sample-off smoke를 통과하는 것이다.
- **Reference scaffolding 1순위: GitHub Template Repository.** CI/Actions workflow 파일까지 그대로 복제되어 friction이 최저. Spring Initializr / Cookiecutter / degit / Yeoman / Maven archetype / Backstage 비교 결과.

### 미구현 항목 (planned)

- sample-ticket entity / repository / use case 코드.
- 12 scenario contract test suite.
- `sample-off` profile bean 분기 / `sample-ticket` runtime isolation.
- dual-mode CI matrix GitHub Actions workflow.
- sample-off / adoption checklist를 검증하는 e2e flow.

## 면접에서 말할 수 있는 범위

### 자신 있게 답할 수 있는 질문

- sample-portfolio / WorkLog fixture가 어떤 운영 계약(envelope / error / capability / transaction / idempotency / outbox)을 트리거하기 위한 시나리오 집합인가.
- WorkLog sample model이 contract trigger 역할을 하도록 구성된 이유. production feature가 아니라 skeleton verification fixture라는 점.
- dual-mode CI matrix (`sample-on` / `sample-off` 둘 다 release-blocking)가 막으려는 회귀 시나리오가 무엇인가.
- sample-off first adoption이 즉시 코드 삭제보다 어떤 안전성을 더 주는가.
- Spring Petclinic / RealWorld 대신 자체 fixture를 둔 이유. contract 매트릭스 부재 / minimum 위반.

### 적당히 답할 수 있는 질문

- GitHub Template Repository vs Cookiecutter trade-off. friction 최저 모델과 generator 시점 sample-off 모델의 시맨틱 차이.
- Backstage golden path 도입 임계점. service template / scorecard / catalog를 따로 운영할 조직 규모 이후.

### 답하면 안 되는 질문 (모른다고 해야 함)

- sample-portfolio 구현 + 로컬 검증 경험. 가능. 단 외부 프로젝트 adoption 사례나 hosted release 차단 사례로 확대하지 않는다.
- 12 scenario matrix 전체가 hosted CI에서 contract 위반을 잡아낸 사례. 별도 확인 필요.
- adoption checklist를 실제 프로젝트에 적용한 결과 / 도입 시간 측정값. **운영 채택 없음.**
- dual-mode CI matrix가 hosted release를 실제 차단한 사례. workflow는 존재하지만 hosted CI 차단 이력은 별도 확인하지 않았다.

## 과장 금지 지점

- "sample-portfolio가 production 도메인이다" → ❌. **contract 검증 도구(fixture)** 이며 production feature가 아니다.
- "Spring Initializr / Cookiecutter가 ca-tmpl과 동급 alternative다" → ❌. 두 도구 모두 **generator 시점에 sample을 빼는 모델**이라, sample-on / sample-off 둘 다 release-blocking으로 검증하는 ca-tmpl 운영 모델과 시맨틱이 다르다.
- "12 scenario를 모두 검증했다" → ❌. **시나리오 정의만 있고**, scenario test suite은 작성되지 않았다.
- "GitHub Template Repository가 모든 면에서 우월하다" → ❌. friction(초기 복제 마찰) 기준 1순위일 뿐, sample 제거 / adoption checklist / operational contract 보존은 ca-tmpl 측에서 별도로 정의해야 한다.
- "Backstage가 skeleton repo의 상위 호환이다" → ❌. 조직 규모 임계점 이후의 IDP 진입점이며 동일 레이어가 아니다.
- "sample-off가 production runtime 운영 안전성을 보장한다" → ❌. sample-off는 build/test classpath 격리 검증이며 운영 채택 사례는 없다.

### Blog-topic ingest: sample-domain-contract-fixture-clean-architecture (2026-07-02)

[[raw/blog-topics/sample-domain-contract-fixture-clean-architecture-2026-06-10]] 는 Clean Architecture 템플릿의 sample domain을 데모 기능이 아니라 validation, mapper, transaction, response, conflict 계약을 실제 흐름으로 검증하는 fixture로 다루는 글감이다.

- **canonical 반영 범위**: sample fixture/adoption canonical의 blog-topic 후보로 연결했다.
- **blogify 전 조건**: 충족. 이 문서는 2026-07-02 기준 코드와 `./gradlew check`로 검증됨.
- **블로그 전 과장 방지**: sample domain이 production feature이거나 scenario suite 전체가 검증됐다고 쓰지 않는다.
- [[raw/blog-topics/sample-fixture-dual-mode-build-matrix-2026-06-25]]: sample domain을 runtime toggle이 아니라 sample-on/sample-off build matrix로 격리하는 글감. hosted CI release-blocking 검증과 local gate matrix를 분리한다.
- [[raw/blog-topics/clean-architecture-reference-project-adoption-2026-06-17]]: 외부 reference project를 그대로 복제하지 않고 contract verification, event reliability, adoption checklist로 분해해 ca-tmpl에 흡수하는 글감. 정확성 감사에서 결함이 지적된 계획 문서는 수정 후에만 근거로 쓴다.

## 관련 개념

- [[wiki/concepts/sample-fixture-and-adoption]]

## Sources

- [[raw/project-notes/ca-skeleton-operational-contract]] — canonical §17 Sample Domain Fixture, §22 Sample-ticket Contract Matrix, §29 Group G-H Sample / adoption
- [[raw/branch-notes/feature-sample-domain-contract-fixture]] — sample-ticket 12 scenario matrix + 6-field minimum + state machine + optimistic lock + idempotency key 결정 SSOT branch
- [[raw/blog-topics/sample-domain-contract-fixture-clean-architecture-2026-06-10]] — sample domain contract fixture 블로그 글감 raw seed
- [[raw/branch-notes/feature-sample-removal-adoption-contract]] — 2-step removal + dual-mode CI matrix + 7-step adoption checklist 결정 SSOT branch
- [[raw/blog-topics/sample-fixture-dual-mode-build-matrix-2026-06-25]] — sample fixture dual-mode build matrix 블로그 글감 raw seed
- [[raw/blog-topics/clean-architecture-reference-project-adoption-2026-06-17]] — reference project adoption 블로그 글감 raw seed

## Cluster / 묶음

<!-- GENERATED: derived-blogs:start -->
- [[wiki/blog/ca-tmpl-sample-fixture-and-adoption-2026-07-02]]
<!-- GENERATED: derived-blogs:end -->