Files
llm-wiki/vault/30-knowledge/projects/ca-tmpl/sample-fixture-and-adoption.md
T

11 KiB

title, source_type, status, confidence, tags, related_projects, last_reviewed
title source_type status confidence tags related_projects last_reviewed
ca-tmpl - Sample Fixture & Adoption 결정 project verified high
ca-tmpl
sample-fixture
template
adoption
actually-implemented
locally-verified
ca-tmpl
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.gradlesampleFixture 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에 흡수하는 글감. 정확성 감사에서 결함이 지적된 계획 문서는 수정 후에만 근거로 쓴다.

관련 개념

Sources

Cluster / 묶음