도메인을 충분히 드러내는 여러 타입을 구축했는데, 이는 컴파일 가능하며 구현체를 작성할때 가이드 역할을 함.

지금까지 도메인을 올바르게 모델링하기 위한 노력을 해왔다면, 이제는 도메인의 모든 데이터가 유효하고 일관되도록 몇 가지 예방 조치가 필요함.

• 신뢰할 수 없는 외부 세계와 구분하여 바운디드 컨텍스트 내에서는 신뢰하는 데이터만 있게 할 것
• 맥락 내 모든 데이터가 항상 유효하다고 확신할 수 있다면 깔끔한 구현은 물론, 불필요한 방어 코드를 피할 수 있음

이 장에서는 신뢰할 수 있는 도메인의 두 가지 측면인 무결성과 일관성을 모델링하는 방법을 살펴봄.

• 무결성: 어떤 데이터가 비즈니스 규칙을 따른다는 의미
  • ex) UnitQuantity는 1에서 1000사이라고 했음. 이 제약 사항을 여러 곳에서 계속 확인해야할까, 아니면 늘 준수한다고 가정할 수 있는가?
  • 주문에는 항상 하나 이상의 주문 항목이 있어야 함
  • 주문을 배송팀으로 보내기 전에는 주문에 올바른 배송 주소를 포함해야 함
• 일관성: 도메인 모델의 여러 부분을 아울러 규칙을 따른다는 의미
  • ex) 주문의 청구 총액은 주문에 포함된 모든 주문 항목 액수의 총합임. 총액이 맞지 않으면 데이터가 일관되지 않음
  • 주문을 접수하면 해당 청구서가 생성되어야 함. 주문은 있지만 청구서가 없으면 데이터가 일관되지 않음
  • 주문에 할인 바우처 코드를 사용하면 바우처 코드를 다시 사용하지 못하게 ‘사용함’ 표시를 해야함. 주문에 쓰인 바우처에 ‘사용함’ 표시가 안 되어 있으면 데이터가 일관되지 않음

→ 이 장에서는 데이터의 무결성과 일관성을 어떻게 보장할지 살펴봄

→ 타입 시스템으로 더 많은 정보를 드러낼수록 별도 문서 없이 올바르게 코드를 구현할 수 있음

6.1 단순값의 무결성

앞서 단순값을 모델링할 때 단순값은 string이나 int로 표현해서는 안되고, WidgetCode 또는 UnitQuantity 같은 도메인이 인식하는 타입으로 표현해야 한다고 했음.

• 실세계 도메인에서 무한한 정수나 무한 길이 문자열이 거의 없어서 도메인 타입으로 나타낸 것으로 타입을 완성한 것이 아님
• 거의 모든 단순값은 어떤 식으로든 제약이 붙음
• OrderQuantity를 일반 정수로 표현할 수 있지만 비즈니스에서 주문 수량이 음수 개이거나 40억 개일 가능성은 매우 낮음