저는 Domain Driven Design을 처음 사용했지만 현재의 C# .net 프로젝트에 적용하려고합니다. 요구 사항 중 하나는 사용자가 엔티티에 비즈니스 규칙을 정의 할 수 있도록 허용하는 것입니다 (예 : 클라이언트 이름 필요). 사용자 그룹마다 다른 규칙 집합을 정의하여 데이터베이스에 저장합니다.도메인 기반 디자인을 사용할 때 데이터베이스에 저장된 비즈니스 규칙 적용
사양 패턴을 설명하는 몇 가지 기사를 읽었으나이 방법을 사용하여 데이터베이스에 저장된 규칙을 적용 할 수 있습니까? 이전 비 DDD 프로젝트에서 나는 엔터티에 IList 속성을 가지고 GetBrokenRules (클라이언트 클라이언트) 메서드를 호출하여 규칙을로드하고 클라이언트가 유효한지 확인했습니다. 같은 종류의 일을하는 것이 더 좋고 사양 패턴을 사용하지 않는 것이 좋을까요?
사양 패턴은 검색 기준 세트로 저장소에서 엔티티를 찾으려고하는 것입니다. 선택적 매개 변수의 긴 목록을 정의하는 대신 사양을 작성하는 대신 사용중인 쿼리 언어로 변환 할 수 있습니다.
비즈니스 규칙은 엔티티 유효성 검사와 관련이 있으므로 사양 패턴이 여기에 적합하지 않다고 말합니다. it's not impossible.
규칙을로드하고 GetBrokenRules 메서드를 호출하는 제안 된 방법이 현명한 선택 인 것 같습니다.
동적 유효성 검사 규칙은 공장 패턴을 비명 친다. 아마도 공장에서 유효성 검사 규칙을 생성하는 과정을 거쳐야 할 것입니다. 지적한 바와 같이, 스펙은 술어를 빌드하기위한 것입니다.
구현에 따라, 단일 규칙을 나타내지 만 속성/모델/컨텍스트가 유효한지 여부를 확인하기위한 조건부를 형성하기 위해 사양을 동적으로 구성 할 수 있습니다.
FluentValidation을 체크 아웃하지 않은 경우 매우 유연하며 고려하지 않은 접근 방식을 제공 할 수 있습니다.
감사합니다. Paolo의 답변을 듣고 나면 Factory Pattern이 FluentValidation을 살펴볼 것입니다. –
사양 패턴은 이와 함께하는 좋은 방법이라고 생각합니다. 아직 읽지 않은 경우 this book을 확인하십시오.
도메인 서비스 내의 데이터베이스에서 빌드 될 복합 사양을 작성해야합니다.
사양에 대한 오해를 해소 해 주신 @Paolo. –