architecture-weblisted

# dddjango-web 프레젠테이션 아키텍처 ## 언제 쓰나 화면을 분해·작성·검수할 때, 조각의 단(view/section/widget)을 정하거나 승격할 때, client 계약 소비·라우팅·design_system 사용을 결정할 때 로드한다. 전문을 읽지 말고 아래 라우팅 표로 필요한 절만 부분 적재한다. 경계: - 파일·폴더·명명·import 방향 **사실** → `discipline-web-houserules` - HTML·삼총사 .py·client·urls **표기** → `implementation-ui` - UI JS 이벤트·DOM·수명 표기 → `implementation-javascript`(coder·감수 역할이 적재) - 이름·함수 형태·중복 등 클린코드 → `discipline-cleancode` - 판별이 갈리는 경계 사례 → 공유 reference `undecidable-web.md`(`discipline-web-houserules` 동봉) ## 핵심 운영 원칙 - web은 «내부의 외부 클라이언트»다 — 백엔드 BC는 실물 API 계약(URL+JSON)으로만 소비, `application/**` import 0. 없는 API는 가정하지 않고 «/dddjango로 발주»를 안내한다 (§1·§6) - 요청 구동 MVVM — VM은 무상태 조립기로 매 요청 재조립된다. watch·구독·상주 상태 없음 (§1) - 형상의 근거는 확인된 동결 시안과 항목별 결정된 이탈이다 — 산문 레이아웃 재설계·직수입 금지. Python/HTML/HTMX/CSS와 승인된 UI JS의 책임을 기존 명세의 `UI 동작 계약`에 연결하고 native로 충분하면 JS를 만들지 않는다 (§1) - 3단은 크기가 아니라 상태 조립(view)/화면 전속(section)/재사용(widget)으로 가른다 — 판별은 위에서부터, 처음 해당하는 것이 답 (§2) - view는 얇은 진입점(URL 바인딩·VM 호출·render·fragment 소유)뿐 — 판단 금지, 서버 표시 판정은 VM이 유일한 자리다 (§3) - state는 불변 dataclass·템플릿이 아는 유일한 모양 — 패키지 타입 직노출 금지(예외: 검증 실패 재렌더용 Django Form 1종 허용). 입력 검증=form(`form/` 조건 생성)·표시 상태=VM 분담 (§3) - section·widget은 dumb — section은 화면 접두 필수·HTMX 재렌더 단위(hx-target), widget은 명시 context만(`with … only`). fragment 진입점은 소속 view 소유·페이지와 같은 auth·CSRF (§4) - 성장하면 단을 옮긴다: 두 번째 화면→widget, 상태 조립 발생→삼총사 승격, BC 어휘 탈피→design_system(widget이 두 번째 영역에서 필요해져도 같은 경로 — 탈피 불가하면 설계 반송) — 타 영역 widget include 금지, state 렌더 또는 명시 context만으로 성립하면 승격 금지 (§5) - 호