arcaC 아키텍처 한눈에 보기 — 다이어그램 3장

arcaC의 구조는 지금까지 저장소 안 설계 문서와 ADR 16편에만 있었어요. 앞의 연재에서 결정의 이유를 다뤘으니, 오늘은 반대로 가볼게요. 시스템 전체를 다이어그램 3장으로, 한 화면씩.

(ADR 16편을 다 읽으실 필요는 없도록요.)

1 · 콘텐츠는 두 개의 타임라인 위에 산다

arcaC 콘텐츠 모델의 뼈대는 편집 타임라인과 공개 타임라인의 분리예요. 편집은 revision 이력을 쌓으며 draft 프로젝션을 갱신하고, 공개 화면은 릴리스에 고정된 프로젝션만 읽어요. 두 세계는 publish라는 명시적 행위로만 만납니다.

눈여겨볼 곳은 가운데의 publish 화살표예요. 프로젝션 재계산이 아니라 이전 릴리스의 INSERT ... SELECT 복제 + 변경분 삽입이고, 릴리스가 잠근 revision의 보호는 코드 리뷰가 아니라 SQL 제약이 담당해요. 상세한 결정 과정은 CQRS 프로젝션 글에서 다뤘습니다.

2 · 트래픽 성격대로 나눈 Worker 3개

운영 배포는 Cloudflare Worker 3개예요. 쓰기 API, 와일드카드 SSR, 홈 SPA는 캐시 정책도 배포 주기도 다르니까 처음부터 분리했어요.

이 그림의 핵심은 화살표보다 "무엇이 DB에 있는가"예요. 어떤 hostname이 어떤 사이트를 서비스하는지는 코드가 아니라 SiteMount 행이 결정해요. 지금 보고 계신 이 블로그 주소도 하드코딩 예외가 아니라 mount 행 하나입니다. 새 사이트 공개에 재배포가 필요 없는 이유가 여기 있어요.

3 · 플러그인은 선언하고, 플랫폼이 조합한다

마지막 그림은 이 플랫폼의 존재 이유예요. 블로그라는 도메인은 플러그인 세 개(선언, 렌더러, 재사용 분류)로 흩어져 있고, 플랫폼 Composer는 그 Manifest들을 도메인 의미를 모른 채 조합해서 게시 시점에 불변 RuntimeSnapshot으로 봉인합니다.

아래쪽의 판정 기준 두 줄이 이 아키텍처의 성적표예요. 플랫폼 패키지에 if blog 분기가 생기면 실패. 두 번째 제품에서 플랫폼이 크게 바뀌어도 실패. 다이어리와 계산기가 올라올 때 이 그림이 그대로 유지되는지가 다음 증명입니다.

덧붙이는 말

이 다이어그램들은 저장소의 docs/architecture/overview.md와 CONTEXT.md 용어집을 기준으로 그렸어요. 그림 속 이름(ContentDraftProjection, SiteMount, RuntimeSnapshot...)은 전부 코드에 실재하는 타입과 테이블입니다. 그림과 코드가 어긋나면 그림이 아니라 코드가 이긴다는 원칙으로, 어긋남을 발견할 때마다 이 글을 고쳐갈 생각이에요.

코어 이야기가 한 조각 더 남았어요. 사용자가 만들어 공유하는 테마를, 코드 한 줄 없이 데이터로만 만든 마지막 편입니다.