Operation Contract (Ch 13)

Operation Contract는 03-system-sequence-diagram|SSD에서 도출된 시스템 이벤트 각각에 대해, 실행 후 도메인 객체들의 상태가 어떻게 변했는지를 명세한 것이다.

언제 쓰는가

유스케이스 텍스트만으로 충분하면 안 써도 된다. 하지만 유스케이스가 모호하거나, 시스템 이벤트의 효과를 정밀하게 기술해야 할 때 유용하다. Larman은 "선택적이지만, 쓰면 08-interaction-diagram|Interaction Diagram 설계가 훨씬 명확해진다"고 말한다.

구조

Operation:    enterItem(itemID: ItemID, quantity: Integer)
Cross Refs:   Use Cases: Process Sale
Preconditions: 진행 중인 Sale이 존재한다
Postconditions:
  - SalesLineItem 인스턴스 sli가 생성되었다 (인스턴스 생성)
  - sli가 현재 Sale에 연결되었다 (연관 형성)
  - sli.quantity가 quantity로 설정되었다 (속성 변경)
  - sli가 itemID에 맞는 ProductSpecification에 연결되었다 (연관 형성)

Postcondition의 세 가지 유형

사후조건은 04-domain-model|Domain Model의 객체들에 대한 상태 변화로 기술한다:

인스턴스 생성/삭제 — "SalesLineItem 인스턴스가 생성되었다"
연관 형성/해제 — "sli가 Sale에 연결되었다"
속성 변경 — "sli.quantity가 qty가 되었다"

이 세 가지만으로 어떤 시스템 이벤트의 효과도 기술할 수 있다.

핵심 포인트

사후조건은 과거 시제의 선언문으로 쓴다. "SalesLineItem을 생성한다"가 아니라 "SalesLineItem이 생성되었다". 이렇게 쓰면 구현 방법(how)이 아니라 결과 상태(what)에 집중하게 된다.

바이브 코딩에서의 활용

Contract의 postcondition은 LLM에게 **함수의 정확한 부수 효과(side effect)**를 알려준다. 테스트 코드 생성에도 직접 활용할 수 있다.

프롬프트 예시:
"enterItem(itemID, qty)의 postcondition을 기반으로 단위 테스트를 작성해줘:

검증할 상태 변화:
1. 새로운 SalesLineItem이 생성되었는가
2. 해당 LineItem이 현재 Sale의 컬렉션에 추가되었는가
3. LineItem의 quantity가 입력값과 같은가
4. LineItem이 올바른 ProductSpecification과 연결되었는가"