OrderStatus 전이 규칙 배치 위치 결정
상태
승인
후보군
| 방안 | 설명 |
|---|---|
| Entity 내부 캡슐화 | OrderStatus.canTransitTo(next) 메서드로 전이 규칙 캡슐화. Order.cancel() / Order.correct() Entity 메서드가 내부 검증 후 전이 |
| UseCase if-throw 분산 | 각 UseCase에서 상태 검증 후 예외 throw |
| DomainService 위임 | DomainService에 상태 검증 로직 집중 |
결정
OrderStatus.canTransitTo(next: OrderStatus): Boolean 메서드로 전이 규칙을 캡슐화한다. Order.cancel() / Order.correct() Entity 메서드가 내부 검증 후 전이한다.
결정 이유
- COMPLETED·CANCELLED 상태에서 정정·취소 시도 시 거부 로직이 필요하다.
- 전이 규칙이 한 곳에 정의되므로 변경 시 누락 위험이 없다.
- domain 단위 테스트로 전체 상태 머신 검증 가능하다.
검토 대안
| 방안 | 기각 이유 |
|---|---|
| UseCase if-throw 분산 | 전이 규칙을 여러 UseCase에 분산 배치하면 변경 시 누락 위험. be-code-convention 위반(UseCase 내 if+throw 금지) |
| DomainService 위임 | Entity의 비즈니스 규칙을 외부로 노출해 Rich Domain Model 원칙에 반함 |
트레이드 오프
- 득: 전이 규칙 단일 정의. domain 단위 테스트로 상태 머신 전체 검증 가능. UseCase 10줄 이내 원칙 준수.
- 실: 특이사항 없음.