도메인 기반 디자인의 동적 속성 집합

Question

검색을 통해 나는이 질문에 대한 답을 찾지 못했습니다. 제 생각에는 상당히 일반적인 디자인 문제입니다.

특정 도메인 개체 :

public class Item { 
    private Long itemSN; 
    private String name; 

    methods, etc... 
} 

우리는 항목을 설명하는 캐릭터 속성의 특정 설정을 저장해야합니다. 무게, 색상, 크기 등이 될 수 있습니다. 시스템은 유연해야하며 변경 가능한 목록 속성을 유지할 수 있어야합니다. 허용 된 속성 이름을 저장해야하며 일부 속성을 적용하는 것이 바람직합니다.

여러 접근법을 시도했지만 모든 항목 개체가 공유하는 공통 제약 조건의 개념은 모든 표준 도메인 모델에 맞지 않습니다.

그래서 제약 조건을 구성 형태로 생각하기 시작했습니다. 각 항목은 (단순 문자열 맵에서) 자체 속성을 가지고 있으며, 반면에 제약 조건은 모든 항목에 공통적 인 구성입니다. 그래서 다음 딜레마가 등장했습니다 ... 도메인 모델에 큰 구멍을 내지 않고 표현하는 방법?

제약 조건을 저장하기 위해 추가 응용 프로그램 계층 개체를 쉽게 도입 할 수 있지만 "허용/필수 속성"은 업무용이므로 도메인 사용자 (일종의 관리자)가 변경할 수 있으므로 그리기가 무서운 느낌입니다. 이 논리는 도메인 계층에서 멀리 떨어져 있습니다.

모든 의견을 환영합니다.

편집 1. 브레인 스토밍을 많이 한 후에 주어진 상황에 맞는 유효한 개체 모델을 만들 수있었습니다. 첫눈에서 일반적인 제약 속성을 캡슐화하는 것은 불가능했지만, 최근 아웃 - 오브 - 도메인 구현은 나에게 아이디어를 준 :

문제의

public class Item { 
    private Long itemSN; 
    private String name; 
    private List<Property> properties; 
} 

코어가 여기에 해결되었다 :

public class Property { 
    private Long propertyId; 
    private String propertyValue; 
    private Constraint constraint; 
} 

public class Constraint { 
    private String name; 
    private Boolean required; 
    private List<String> allowedValues; 
} 

그래서를 , 각 속성에는 이름, 허용 된 값 및 필수 상태를 지정하는 값 및 제약 조건 객체가 있습니다. 이 방법으로 제약 객체는 많은 프로퍼티에 의해 공유 될 수 있으며,이 프로퍼티는 자체의 값을 가질 수 있습니다. DB 매핑에 약간의 복잡성이 추가되고 성능이 향상되지만 모든 도메인 로직이 도메인 객체에 유지됩니다.

모든 개선, 제안 및 의견을 환영합니다.

Answer 1

이 문제는 특수 효과 사용으로 매우 합리적으로 해결할 수 있습니다. 어노테이션을 사용하면 코더가 주석을 사용하지 않고 사용자 정의 필드에 동일한 제약 조건을 적용 할 수있게하면서 속성에 제약 조건을 지정하기 만하면 속성 사용에 대한 언어 사용을 계속할 수 있습니다.

JSR-349은 이러한 제약 조건을 적용하기위한 Java 표준입니다. Hibernate validator은 잘 알려진 구현입니다.