BDD/DDD 기본 엔티티 유효성 검사를위한 사양은 어디에 두어야합니까?

Question

또는 기본 엔터티 유효성 검사가 사양으로 간주됩니까?

일반적으로 실제 엔티티에서 기본 엔티티 유효성 검사 (이름을 null 또는 비워 둘 수 없으며 xxx보다 클 수 있어야 함)를 유지하는 것이 좋습니다.

사양에서 어떤 모양입니까? 각 필드에 대한 스펙을 갖거나 하나의 EntityIsValid 유형 스펙으로 모두 감쌀 것입니까?

Answer 1

일단 사람들이 DDD에 대해 조금 배웠다면, 그들은 Specification 패턴을 선택하여 어디에서나 적용 할 수 있습니다. 그건 정말 골든 해머 안티 패턴입니다.

사양 패턴을위한 장소와 내가 이해 한 방식으로 Domain-Driven Design을 이해하는 것은 엔터티와 독립적으로 비즈니스 규칙을 변경해야 할 때 적용 할 수있는 디자인 패턴이라는 것입니다.

DDD는 반복적 인 접근 방식이므로 첫 번째 테이크 업에서 '올바르게'가져올 필요가 없습니다. 엔티티 내부에서 기본적인 유효성 검사를 시작하는 것으로 시작합니다. 이는 OOD에 대한 기본 개념과 잘 부합됩니다. 개념을 나타내는 객체가 유효한 데이터 범위를 알 수 있기 때문입니다.

제약 조건이 불변량으로 표시되도록 엔터티를 디자인해야하므로 제약 조건을 위반하는 인스턴스를 만들 수 없으므로 대부분의 경우 명시 적 유효성 검사가 필요하지 않습니다. 당신은 이름이 null 또는 비어있을 수 없다는 규칙이있는 경우

, 당신은 적극적으로 직접 엔티티에 그것을 적용 할 수 있습니다 : 이름이 null이 될 수 없다는 규칙은 이제 클래스의 불변

public class MyEntity 
{ 
    private string name; 

    public MyEntity(string name) 
    { 
     if(string.IsNullOrEmpty(name)) 
     { 
      throw new ArgumentException(); 
     } 
     this.name = name; 
    } 

    public string Name 
    { 
     get { return this.name; } 
     set 
     { 
      if(string.IsNullOrEmpty(value)) 
      { 
       throw new ArgumentException(); 
      } 
      this.name = value; 
     } 
    } 
} 

입니다

: MyEntity 클래스가 규칙이 깨진 상태가되는 것은 이제 불가능합니다.

나중에 규칙이 더 복잡하거나 다양한 개념간에 공유되는 것을 발견하면 항상 사양으로 추출 할 수 있습니다.

Answer 2

엔티티에는 데이터와 비헤이비어가 모두 있으므로 엔티티에서 불변성을 보장하면 IMHO로 이동할 수 있습니다. 그렇지 않으면 anemic domain model [Fowler]로 끝날 수 있습니다.

Mark Seemann이 제안한대로 컨텍스트에서 설정 자의 규칙을 적용 할 수있는 경우 모델에 "IsValid"및/또는 "BrokenRules"논리가 모두 없기 때문에 상황이 좋을 것입니다.

우리가 우리 자신은 비록 전술 솔루션을 필요로 발견 어디 두 가지 상황에서 봤는데 :

1. 고전 응답/요청 웹 솔루션을 어디에 저장 실패에 따라 기업의 웹 페이지가 표시 모든 깨진 규칙 .

2. 외부에서 업데이트되는 데이터베이스에서 모델을 읽습니다 (따라서 ORM이 설정자를 사용하지 않는 한 엔티티가 유효하지 않을 수 없습니다. 그러나 ORM이 설정자를 사용하도록하지 않는 한 엔티티가 유효하지 않습니다. 타당성에 대해).