83 lines
4.5 KiB
Markdown
83 lines
4.5 KiB
Markdown
---
|
|
title: blog-topic / boundary-validation-mapper-responsibility-map
|
|
source_type: blog-topic
|
|
status: raw
|
|
related_branches: [feature-boundary-validation-mapping-contract]
|
|
related_projects: [ca-tmpl]
|
|
tags: [blog-topic, ca-tmpl, validation, mapper, bean-validation, partial-update, anti-corruption-layer]
|
|
created: 2026-07-02
|
|
status_label: ready-for-canonical
|
|
target_audience: backend-engineer
|
|
inspiration_url:
|
|
archive_url:
|
|
---
|
|
|
|
# blog-topic: boundary-validation-mapper-responsibility-map
|
|
|
|
> Layer: `raw/blog-topics/` — 채용공고가 아닌 작업·학습·트러블슈팅에서 나온 블로그 글감 원석. 다듬어진 블로그 초안은 canonical (`wiki/concepts/` 또는 `wiki/projects/`) 정제 후 `/blogify` 또는 수동 작성으로 `wiki/blog/`에 별도 작성한다.
|
|
|
|
## Parent / 부모
|
|
|
|
- [[raw/branch-notes/feature-boundary-validation-mapping-contract]] — 입력 경계 검증과 DTO-domain mapper 책임을 B1-B8로 분리한 verified branch에서 나온 상위 글감.
|
|
|
|
## 트리거 / Trigger
|
|
|
|
- 트리거 유형: `branch-work`
|
|
- 트리거 날짜: 2026-07-02
|
|
- 트리거 연결 노트: [[raw/branch-notes/feature-boundary-validation-mapping-contract]]
|
|
|
|
## 글감 / Topic seed
|
|
|
|
- 한 문장 요지: 입력 syntax, application policy, domain invariant, persistence integrity, mapper normalization 책임을 한 계층에 몰아넣지 않고 경계별로 나눈 이유를 정리한다.
|
|
- 예상 제목 후보:
|
|
- Clean Architecture에서 validation과 mapper 책임을 나누는 법
|
|
- DTO mapper를 단순 변환기가 아니라 경계 정책으로 본 이유
|
|
|
|
## 핵심 주장 후보 / Claim candidates
|
|
|
|
- 사실 후보:
|
|
- B1-B8 결정 묶음이 branch의 decision 영역과 extraction 영역에 존재한다 — 근거 후보: [[raw/branch-notes/feature-boundary-validation-mapping-contract]] section+line `:87-101`, `:385-407`.
|
|
- 경험 후보:
|
|
- 기존 Jackson default typing CVE 글감은 B5에 가까운 좁은 보안 사례라, B1-B8 전체 책임 지도 글감은 별도로 필요하다 — 근거 후보: lane-01 inventory, 기존 [[raw/blog-topics/archunit-jackson-default-typing-cve-2019-14379-block-2026-05-29]].
|
|
- 의견/해석 후보:
|
|
- mapper를 "보일러플레이트 제거 도구"로만 보면 normalization, masking, public-field boundary 같은 정책 책임이 흐려진다.
|
|
|
|
## Outline seed
|
|
|
|
1. validation이라는 단어가 너무 넓다 — syntax, policy, invariant, persistence integrity는 실패 위치와 책임자가 다르다.
|
|
2. mapper는 단순 변환기만은 아니다 — 외부 DTO와 내부 domain 사이에서 normalization과 public-field 정책을 고정한다.
|
|
3. ArchUnit rule은 boundary drift를 데이터로 만든다 — 계층 의도를 빌드 실패 조건으로 바꾸는 것이 핵심이다.
|
|
|
|
## Canonical 전환 후보 / Canonical extraction candidates
|
|
|
|
- `wiki/projects/ca-tmpl/boundary-validation-mapping.md` 후보:
|
|
- ca-tmpl에서 B1-B8로 검증/매핑 책임을 분리한 프로젝트 결정과 검증 등급.
|
|
- `wiki/concepts/boundary-validation-and-dto-mapping.md` 후보:
|
|
- Bean Validation, partial update, anti-corruption mapper 책임 분리 일반 개념.
|
|
- 필요한 추가 검증:
|
|
- B1-B8 항목의 실제 구현/테스트 상태와 `locally-verified` 범위 확인.
|
|
|
|
## Sources / 근거 후보
|
|
|
|
- [[raw/branch-notes/feature-boundary-validation-mapping-contract]] — B1-B8 결정과 extraction 후보의 근거.
|
|
- [[raw/blog-topics/archunit-jackson-default-typing-cve-2019-14379-block-2026-05-29]] — 좁은 하위 topic과의 중복 경계.
|
|
|
|
## 미해결 / Unknown
|
|
|
|
- 아직 확인해야 할 사실: B1-B8 각각의 구현 파일/테스트 anchor.
|
|
- 과장하면 안 되는 부분: 모든 validation 책임을 이 구조 하나로 해결한다고 쓰면 안 된다. ca-tmpl의 경계 분리 결정과 검증된 범위로 제한한다.
|
|
- 블로그로 쓰기 전에 필요한 canonical 정제: project 문서의 verified 항목과 concept 문서의 일반 개념을 분리.
|
|
|
|
## Decision / 처리 결정
|
|
|
|
- 액션: `promote-to-canonical`
|
|
- 이유: `wiki/projects/ca-tmpl/boundary-validation-mapping.md` 에 boundary/mapper 책임 분리 글감으로 반영했다.
|
|
- 다음 단계: source canonical이 `verified` 상태이므로 이후 `blogify` 대상으로 삼을 수 있다. 단 ca-tmpl 내부 taxonomy와 일반 표준을 혼동하지 않는다.
|
|
|
|
## Related / 관련
|
|
|
|
- 관련 branch: [[raw/branch-notes/feature-boundary-validation-mapping-contract]]
|
|
- 관련 error:
|
|
- 관련 interview prep:
|
|
- derived blog: 생성 전. 생성 시 `wiki/blog/boundary-validation-mapper-responsibility-map-YYYY-MM-DD.md` 후보
|