62 lines
4.2 KiB
Markdown
62 lines
4.2 KiB
Markdown
---
|
|
title: interview-prep / clean-architecture-domain-onboarding-guardrails
|
|
source_type: interview-prep
|
|
status: raw
|
|
related_branches: [feature-domain-feature-onboarding-contract]
|
|
related_projects: [ca-skeleton]
|
|
tags: [interview-prep, ca-skeleton, architecture, testing, clean-architecture, multi-module]
|
|
created: 2026-06-25
|
|
status_label: collecting
|
|
---
|
|
|
|
# interview-prep: clean-architecture-domain-onboarding-guardrails
|
|
|
|
> Layer: `raw/interviews/` — 실행 가능한 Clean Architecture onboarding guardrail 경험에서 나온 면접 질문 원석.
|
|
|
|
## Parent / 부모
|
|
|
|
- [[raw/branch-notes/feature-domain-feature-onboarding-contract]] — 이 branch에서 문서 checklist를 ArchUnit/JUnit dry-run guardrail 로 구현했기 때문에 나올 수 있는 질문.
|
|
|
|
## 질문 / Question
|
|
|
|
- 질문 원문: Clean Architecture 템플릿에서 새 도메인 기능을 추가할 때 계층 경계가 무너지지 않는다는 것을 어떻게 검증했나요?
|
|
- 출처: 예상 질문
|
|
- 받은 날짜·맥락 (실제 받은 경우): 해당 없음
|
|
|
|
## 질문 의도 추론 / Why this question
|
|
|
|
- 핵심 평가 대상: 아키텍처 경계 자동화, 테스트 설계, 문서 계약을 실행 가능한 guardrail 로 전환한 경험.
|
|
- 함정 / 흔히 빠지는 답변 패턴: “컨벤션으로 조심했다” 수준에서 끝내고 실패 fixture나 negative test evidence를 제시하지 못하는 답변.
|
|
- 따라올 만한 후속 질문: ArchUnit 정적 분석으로 잡지 못하는 한계는 무엇이며 어떻게 보완했나요?
|
|
|
|
## 답변 재료 / Raw answer material
|
|
|
|
- 사실 1: onboarding 기준은 `domain-core` → `application-core` → `adapter-*` 방향의 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.
|
|
- 내가 직접 한 경험: `DomainFeatureOnboardingContractTest`와 `dev.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 / 근거
|
|
|
|
- [[raw/branch-notes/feature-domain-feature-onboarding-contract]] — 이번 구현과 검증의 primary evidence.
|
|
- [[raw/errors/gradle-wrapper-sandbox-lock-2026-06-25]] — 로컬 검증 중 발생한 Gradle sandbox 문제.
|
|
|
|
## 미해결 / 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-verified`를 `prod-verified` 또는 범용 best practice로 말하지 말 것.
|
|
|
|
## Related / 관련
|
|
|
|
- 관련 블로그 글감: [[raw/blog-topics/executable-clean-architecture-onboarding-2026-06-25]]
|
|
- 답변 derive 후 위치: 생성 전
|