공통 기계와 제품 경계를 같이 지켜
작업장 가족에는 진실 둘이 있어. queue, claim, stage, review, landing 같은 lifecycle 기계는 여러 형제에서 같을 수 있고, 그래도 각 형제는 같은 제품이 아니야. 첫 진실을 버리면 coupled copy 가 생기고, 둘째를 버리면 kernel 이 모든 domain exception 을 먹는 god-object 가 돼.
root class 는 work item identity, status transition, claim ownership, review round, landing record 처럼 중립 행동을 소유해. quest, publication, accessibility audit 같은 결과 명사는 몰라야 해. 그 말들이 public API 로 올라오면 다음 소비자가 첫 제품 세계관을 억지로 상속하게 돼.
concrete workshop 은 stage policy, template, UI vocabulary, material rule, verification hook 을 공급해. 이름과 색만 바꾸는 wrapper 가 아니야. 어떤 proof 가 필요하고 landed 가 분야에서 무슨 뜻인지 결정하니 제품 경계를 실제로 소유해.
의존은 한 방향이어야 해. concrete 가 kernel 에 기대고 kernel 은 concrete 이름을 import 하지 않아. workshop 별 if 문이 root 에 들어오는 순간 새 형제마다 kernel 배포가 필요해지고 재사용 층이 제품 catalog 를 소유하기 시작해.
공개 어휘를 감사해
type, function, serialized field, error event 를 훑고 제품 하나를 알아야 이해되는 명사를 표시해. 공통 행동이면 정확한 capability 로 바꾸고, 로컬 은유면 adapter 에 남겨. 최대 추출이 아니라 주인 하나당 약속 하나가 목표야.
경계가 무너지는 전형적인 장면
새 작업장이 review 단계 하나만 다르게 쓴다고 해보자. 커널 안에 if workshop == ... 를 더하는 게 제일 빨라 보여. 하지만 그 한 줄은 커널이 제품 목록을 알기 시작했다는 뜻이야. 대신 구체 policy 가 required stages 와 review hook 을 공급하게 두면 root 는 “필수 증거를 검사한다”는 기계 약속만 지켜. 다음 형제가 와도 커널 코드는 새 이름을 배울 필요가 없어. 그게 root class 가 실제 root 로 남았다는 현장 증거야.