Files
llm-wiki/raw/interviews/clean-architecture-domain-onboarding-guardrails.md
T

4.2 KiB

title, source_type, status, related_branches, related_projects, tags, created, status_label
title source_type status related_branches related_projects tags created status_label
interview-prep / clean-architecture-domain-onboarding-guardrails interview-prep raw
feature-domain-feature-onboarding-contract
ca-skeleton
interview-prep
ca-skeleton
architecture
testing
clean-architecture
multi-module
2026-06-25 collecting

interview-prep: clean-architecture-domain-onboarding-guardrails

Layer: raw/interviews/ — 실행 가능한 Clean Architecture onboarding guardrail 경험에서 나온 면접 질문 원석.

Parent / 부모

질문 / Question

  • 질문 원문: Clean Architecture 템플릿에서 새 도메인 기능을 추가할 때 계층 경계가 무너지지 않는다는 것을 어떻게 검증했나요?
  • 출처: 예상 질문
  • 받은 날짜·맥락 (실제 받은 경우): 해당 없음

질문 의도 추론 / Why this question

  • 핵심 평가 대상: 아키텍처 경계 자동화, 테스트 설계, 문서 계약을 실행 가능한 guardrail 로 전환한 경험.
  • 함정 / 흔히 빠지는 답변 패턴: “컨벤션으로 조심했다” 수준에서 끝내고 실패 fixture나 negative test evidence를 제시하지 못하는 답변.
  • 따라올 만한 후속 질문: ArchUnit 정적 분석으로 잡지 못하는 한계는 무엇이며 어떻게 보완했나요?

답변 재료 / Raw answer material

  • 사실 1: onboarding 기준은 domain-coreapplication-coreadapter-* 방향의 module slice다. 근거: raw/branch-notes/feature-domain-feature-onboarding-contract D1, D2.
  • 사실 2: read-only slice는 command/write port 없이 query/use case/mapper/controller와 contract 검증으로 충분하다고 정의했다. 근거: raw/branch-notes/feature-domain-feature-onboarding-contract D3.
  • 사실 3: write slice는 command/use case/write port/persistence/transaction boundary가 함께 있어야 한다. 근거: raw/branch-notes/feature-domain-feature-onboarding-contract D4, D8.
  • 내가 직접 한 경험: DomainFeatureOnboardingContractTestdev.caskeleton.onboarding.* Ticket dry-run fixture, use_case_capability_matches_transaction_port_boundary ArchUnit rule, shared-contract negative fixture를 구현하고 ./gradlew test까지 통과시켰다. 근거: raw/branch-notes/feature-domain-feature-onboarding-contract §구현 결과.
  • 트레이드오프: ArchUnit direct-call 분석은 빠르고 CI 친화적이지만 helper 뒤에 숨은 transaction boundary는 잡지 못한다. 이 한계는 branch D8의 Open Risk로 남겼다.
  • 한계 / "이건 안 해봤다": 운영 환경 검증은 없다. 이번 증거 등급은 locally-verified다.

Sources / 근거

미해결 / Unknown

  • 모르는 것 1: 실제 downstream fork 에서 같은 fixture strategy가 과도한 boilerplate로 받아들여질지.
  • 모르는 것 2: helper-mediated transaction boundary를 자동 분석으로 더 깊게 잡을 필요가 있는지.
  • 확인 방법: downstream adoption branch 또는 실제 새 도메인 branch에서 fixture 없이 production slice를 추가해 guardrail false positive/negative를 관찰한다.

답변 경계 / Answer boundary

  • 자신 있게 말할 수 있는 범위: ca-tmpl local Gradle test/ArchUnit 수준에서 새 도메인 onboarding 계약을 실행 가능한 guardrail 로 구현하고 검증했다.
  • "이 부분은 공식 문서를 다시 보고 답변드리겠습니다" 라고 해야 하는 부분: ArchUnit이 Java call graph 전체를 완전 분석한다는 식의 주장은 하지 않는다.
  • 절대 과장하지 말 것: locally-verifiedprod-verified 또는 범용 best practice로 말하지 말 것.