하나의 canonical state

"여행을 한 번 바꾸면 모든 view가 다시 그려져. 이건 UI 트릭이 아냐. 아키텍처 전부야."

아래 깔린 model

Waystone의 모든 화면 아래엔 canonical 여행 state가 딱 하나 있어. 그 aggregate root가 Journey야. lifecycle, 여행자, 목적지 범위, 날짜, 현재 plan revision, departure baseline, consultation 스레드로 가는 링크를 소유해. 거기 매달린 게 날들, 장소랑 그 journey 안에서의 의미들, route들, 추천들, 결정들, 그리고 무슨 일이 있었는지의 기록이고. 그 구조화된 state가 model이야. 네가 볼 수 있는 건 전부, itinerary든 globe든 journey map이든 일일 로그든, 그것의 view야.

이건 배관이 아니라 다형성이야

OO Quest를 했으면 익숙할 거야. 아빠가 세상 어디서나 보는 그 아이디어니까. model 하나, 다형적 view 여럿. itinerary는 날들이랑 그 순서를 읽어. 지도는 장소랑 route를 읽고. globe는 어느 journey가 세상 어디를 건드렸는지 읽어. 로그는 day entry를 읽고. 각 view는 같은 canonical state에 다른 질문을 던지고 답을 자기 방식으로 렌더해. 그리고 결정적으로, 어떤 view도 model을 편집하지 않아. view는 reader야. model이 바뀌면 걔들 전부가 새 진실에서 다시 그려. 누구도 어긋날 사본을 안 쥐고 있었으니까.

왜 이게 정직한 설계야

반대 방식, 그러니까 화면마다 여행 사본을 따로 쥐게 두는 건 불일치로 가는 길이야. 지도는 이걸 말하고 itinerary는 저걸 말하면, 이제 둘 다 진짜라고 우기는 여행이 두 개야. 모든 표면을 model 하나의 projection으로 만들어서, Waystone은 여행이 언제나 하나뿐이게 보장해. 그 보장의 값은 규율이야. view가 '그냥 편해서' 뭔가 조용히 저장하게 두려는 유혹을 버텨야 하거든. 개인 은닉처 하나하나가 미래의 divergence야. 지도가 아무것도 저장 안 하는 건 한계가 아냐. 지도가 언제나 진실을 말한다는 약속이야.

Code

하나의 model, 여러 reader (형태 스케치)·text

Journey (canonical model)
  lifecycle, 여행자, 날짜, plan_revision, baseline
  |- days[]        (local-calendar 컨테이너)
  |- places[]      (+ journey-scope Waystone 의미)
  |- routes[]      (planned + actual geometry)
  |- decisions[]   (아빠가 뭘 골랐고, 왜)
  '- events[]      (날 안의 현실 단위)

     ^        ^        ^        ^
 itinerary  globe     map      log        <- view
 days       journeys  places   entries
 읽음       읽음      읽음     읽음

# 모든 view가 model을 읽어. 어떤 view도 편집 안 해.
# model을 한 번 바꾸면 모든 view가 새 진실에서 다시 그려.

Exercise

같은 데이터를 두 가지 넘게 보여주는 앱을 봐. 월/주/일 view 캘린더, board/list/timeline 프로젝트 도구. 물어봐. 모든 view가 읽는 model이 아래 하나 있어, 아니면 view마다 drift할 수 있는 자기 state를 쥐고 있어? 같은 데이터의 두 view가 안 맞았던 순간을 찾아봐. 그 불일치가 개인 사본이 새는 거야.

Hint

깔끔한 테스트가 있어. 한 view에서 편집한 게 즉시 다른 모든 view에 정확히 반영되면, 아래 model이 하나 있는 거야. 두 번째 view를 'refresh'하거나 'sync'해야 했던 적 있으면, 그건 자기 사본을 쥐고 있던 거고, 사본은 drift해.