Assessment를 연다

한 장 — 전체 설계도

판정 설계 전체를 한 장에

세 가지 분리가 한 그림에 있다 — 도메인 분리(세 개의 존: 빌려 쓰는 사실 / 요청 동안만 존재하는 공장 / 영속되는 답), 책임 분리(역할 4색: 재료·규칙·값·라인), 그리고 관계 문법(흐름은 실선으로 아래로, ID 참조는 점선으로 위로).

확대 1 — 객체와 협력

객체는 필드가 아니라 메시지로 산다

실측 질문 하나 — "18:40, 농수산물시장(순번 61), 탈 수 있어?" — 가 네 번의 메시지로 답이 된다. 각 객체는 받는 메시지(메서드)가 명함이고, 판단에 필요한 규칙을 자기 안에 갖고 있다. 서비스의 if문이 아니다.

스스로를 지키는 값들 — 잘못된 값은 태어나지 못한다

우테코 문법 그대로다 — LottoNumber가 setter 없이 검증과 비교만 갖듯, 값이 자기 규칙을 독점한다.

확대 2 — 카드 속 구조

판정 한 장에 무엇이 들었나

확대 3 — 답이 만들어지는 길

답은 조립 라인에서 나온다

질문 하나가 일곱 단계를 지나 위의 카드가 된다. 각 단계는 자기가 안 하는 일이 명확하다 — 그래서 모델을 갈아 끼워도, 백테스트를 돌려도 라인의 모양이 안 바뀐다.

모델은 카트리지다 — 슬롯 4개

계약은 두 가지뿐 — 라벨링(관측 1건 → 라벨)과 추정(봉투 → 답). 빈 슬롯에도 이름이 있어서, v1의 "몇 대·몇 분" 칸은 0이 아니라 사유 있는 안 함이 된다.

확대 4 — 실측으로 본 판정

2분 만에 답이 뒤집힌다

8/13 저녁, 3330 농수산물시장. 실제 관측으로 조립한 판정 두 장 — 직전 버스를 고르는 규칙 한 줄이 답을 지배한다. 그래서 규칙이 코드 구석이 아니라 도메인에 박제되고, 계보가 어느 규칙이었는지 기록한다.

실패도 답이다 — 미추정 사유 7종

미추정은 예외(throw)가 아니라 사유를 품은 값 — 블랙잭 Bust와 같은 문법. 어느 단계가 접었는지가 화면 배지(dataState)까지 그대로 이어진다.