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
@@ -65,6 +65,16 @@ tech-log-frontend : 31afb4d 이후

 앞선 종류들과 여기서 갈린다. Case 와 Reference 와 Question 은 상세 화면이 있어서 목록 항목이 가볍고 상세를 부르면 나머지가 온다. 결정에는 상세를 부를 곳이 없으므로 화면이 그리는 칸이 전부 목록 항목에 있어야 한다.

+## 종류마다 사는 곳이 다르다
+
+편집 화면이 고르는 유형 다섯은 하나의 애그리거트가 아니다. 각 유형이 자기 애그리거트와 테이블을 갖고, 문서 세 종류만 한 테이블을 공유한다.
+
+결정은 그중 문서 테이블에 살지 않는다. 프로젝트 안에서만 읽히므로 자기 목록도 자기 상세 화면도 없고, 공개 주소가 프로젝트 결정 목록 위의 앵커다.
+
+종류별 목록 주소 표에서도 결정만 다른 규칙을 따른다. 그 표의 javadoc 이 그것을 적어 둔다.
+
+> 결정은 프로젝트 안에서만 읽히므로 자기 목록이 없다. 그 자리를 `/projects` 로 두는 것은 빠뜨린 것이 아니라 그렇게 정한 것이고, 표에 적혀 있으니 다음 사람이 구분할 수 있다.
+
 ## 네 증상이 한 원인이었다

 목록 항목에 `title`·`summary`·`consequences`·`evidence` 가 빠져 있었고, 화면 쪽이 없는 칸을 각자 메우고 있었다.