재사용보다 경계가 먼저야

중립 이름보다 중립 계약이 먼저야

quest_slug 를 item_key 로 바꿨다고 곧바로 reusable API 가 되진 않아. item_key 가 immutable 한지, 어떤 scope 에서 unique 한지, 누가 만들고 언제 사라지는지 없으면 새 단어만 물컹해. 분야 명사를 지우는 일과 행동을 정확히 만드는 일을 같이 해야 해.

kernel 이 알 만한 건 work item, pipeline, claim, required stage, review round, landing record 같은 capability 야. 그 item 이 quest 인지 audit 인지 release 인지는 adapter 가 가장자리에서 번역해. 그래야 product voice 는 살고 shared layer 는 한 은유에 묶이지 않아.

error message 도 public contract 일부야. root error 는 “claim owner 가 다르다”, “required stage 가 빠졌다”처럼 깨진 mechanic 을 말해. concrete layer 는 거기에 제품 맥락을 붙일 수 있어. kernel 이 corpus 나 publish 를 직접 말하면 다음 workshop 이 거짓 번역을 해야 해.

중립화가 의미 차이를 숨기면 더 나빠. 한 제품의 published 와 다른 제품의 reviewed 를 complete 로 합쳤는데 관찰 가능한 상태가 다르면 공통점이 아니야. 교집합 behavior 를 먼저 쓰고 그다음 이름을 골라.

boundary test 를 써

kernel public symbol 마다 concrete 이름 없이 invariant 를 설명해봐. 설명이 안 되면 local policy 로 돌려보내. 설명은 되지만 너무 느슨하면 capability 를 더 정확히 정의해야 해.

reuse 는 먼저 거절 목록을 쓰는 데서 시작해. shared machinery 를 뽑기 전에 kernel 이 절대 소유하지 않을 것을 밝혀. domain judgment, destination semantics, product-specific success criteria 같은 것들이야. 재사용 층은 API 만큼 exclusions 가 또렷할 때 믿을 수 있어.

중립화가 실패한 예

publish 를 complete 로 바꾸기만 했다고 해보자. 한 제품에서 publish 는 외부에 공개됐다는 뜻이고, 다른 제품에서 complete 는 내부 검토만 끝났다는 뜻이면 새 단어가 차이를 숨겼을 뿐이야. 중립 capability 는 둘의 공통 행동만 담아야 해. 예를 들면 landed 는 “작업이 지명한 목적지에 결과가 놓였고 기록이 닫혔다”처럼 관찰 가능한 계약을 가져야 하지. 이름을 지우기 전에 의미 교집합부터 증명해.

Code

Map domain vocabulary at the adapter edge·python

from dataclasses import dataclass

@dataclass(frozen=True)
class WorkItem:
    key: str
    state: str

DOMAIN_TO_KERNEL = {"draft": "queued", "in-review": "taken", "published": "landed"}

def adapt(quest_id: str, quest_state: str) -> WorkItem:
    return WorkItem(key=quest_id, state=DOMAIN_TO_KERNEL[quest_state])

assert adapt("sample", "published").state == "landed"

중립 이름보다 중립 계약이 먼저야

boundary test 를 써

중립화가 실패한 예

Code

External links

Exercise

Progress

댓글 0