docs(TechLog): 도메인 규칙을 기록에 엮는다

§1.4 로 세운 도메인·비즈니스 규칙을 그것이 실제로 설명하는 기록에 넣었다. 프로젝트가 문서 게시 파이프라인을 안 타는 이유 → 화면 다섯이 비어 있던 Case 홈 focus 설정이 FK 없이 사는 설계 → 「열린 질문이 없습니다」 Case 결정이 자기 화면을 안 갖는 이유 → 목록이 문서 전체를 실어야 했던 Case 게시가 단계마다 다른 코드로 거절하는 설계 → 화면이 추측 셋을 출력한 Case (반대 사례) 종류마다 애그리거트와 테이블이 다르다 → 매퍼가 종류를 판정해야 하는 Case 축을 지우면 연결만 끊고 주제를 지우면 거절하는 이유 → 축 Concept 개념이 문서 테이블에 얹힌다 → 열세 곳 Case 화면 상태와 도메인 상태가 원래 갈려 있었다 → 이름을 두 번 바꾼 Case Case 본문 중앙값 675 → 1,342 자. 검사 넷 전부 통과한다. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-07 19:37:13 +09:00
parent 4769e52e48
commit e9f6a93327
9 changed files with 79 additions and 2 deletions
@@ -84,6 +84,14 @@ case TOPIC_IN_USE -> "이 주제를 쓰는 기록이 있어 삭제할 수 없습

 그래서 화면이 실어 나를 수 있는 것은 이 고정 문구다. 서버 안의 진단 메시지는 서버 로그에만 남는다.

+## 같은 저장소가 반대로 만든 경로
+
+게시 경로는 정반대로 설계돼 있다. 단계마다 다른 계약 코드로 거절하고, 그 이유가 use case 의 javadoc 에 적혀 있다.
+
+> 단계별 실패가 서로 다른 계약 코드로 나가는 것이 이 use case 의 핵심이다. `DOCUMENT_VALIDATION_FAILED`(지금 검증하면 실패)와 `VALIDATION_STALE`(통과했으나 전제가 바뀜)은 다른 사건이고, 작성자가 해야 할 일도 다르다 — 전자는 고치는 것이고 후자는 다시 검증하는 것이다.
+
+미리보기도 만료된 것과 이 버전을 설명하지 않는 것이 다른 코드로 갈린다. 삭제 실패만 그 갈래를 화면에서 다시 뭉갰다.
+
 ## 무엇이 구분되지 않았나

 세 원인은 해야 할 일이 다르다.
@@ -84,7 +84,7 @@ REFERENCE → 적용 기준    DECISION → 설계 결정
 QUESTION → 열린 질문
 ```

-두 안이 말하는 것은 같다. 「직접 해보니」와 「검증 기록」은 둘 다 그 글이 재현한 결과라고 말한다. 갈린 것은 이 사이트의 다른 글들이 쓰는 어조와 맞느냐다.
+두 안이 말하는 것은 같다. 「직접 해보니」와 「검증 기록」은 둘 다 그 글이 재현한 결과라고 말한다. 갈린 것은 이 사이트의 다른 글들이 쓰는 어조와 맞느냐였다.

 ## 이름 표가 하나였기 때문에 두 번 바꿀 수 있었다

@@ -96,6 +96,19 @@ QUESTION → 열린 질문

 이름을 바꿔도 이 표는 그대로였다. 표시 이름과 지식 상태가 다른 축이라 따로 두었기 때문이다.

+## 화면 이름과 도메인 상태는 원래 다르다
+
+이 저장소는 화면에 보이는 값과 도메인이 들고 있는 값을 이미 갈라 두고 있었다.
+
+| 계약이 화면에 주는 값 | 도메인이 들고 있는 값 |
+|---|---|
+| 질문 상태 : OPEN · RESOLVED | OPEN · INVESTIGATING · PAUSED · RESOLVED |
+| 결정 상태 : PROPOSED · ADOPTED | PROPOSED · ACCEPTED |
+
+질문 상태 셋이 화면에서 하나로 접히고, 그 역방향 변환은 도메인 상태를 덮어쓰지 않는다. 결정의 `ACCEPTED` 는 화면에서 `ADOPTED` 로 보인다.
+
+종류 이름을 두 번 바꾸면서 계약을 건드리지 않은 것은 새로 정한 규칙이 아니라 이미 있던 규칙을 따랐다.
+
 ## 계약의 kind 는 그대로 뒀다

 바꾼 것은 화면에 보이는 이름이다. 계약의 종류 값은 다섯 그대로이고 주소도 그대로다.