検索を行った後、これに答える質問を見つけることができませんでした。私の意見では、かなり一般的な設計の問題です。
指定されたドメインオブジェクト：
public class Item {
private Long itemSN;
private String name;
methods, etc...
}
アイテムを説明するStringプロパティの特定のセットを格納する必要があります。重量、色、サイズなどがあります。システムは柔軟性があり、変更可能なリストのプロパティを保持できる必要があります。許可されたプロパティ名を保存する必要があり、できればそれらのいくつかを強制する必要があります。
いくつかのアプローチを試しましたが、すべてのItemオブジェクトで共有される共通の制約の概念は、標準のドメインモデルに適合しません。
それで、私は制約を構成の形式として考え始めました。各アイテムには独自のプロパティ（単純な文字列マップ）がありますが、制約はすべてのアイテムに共通の構成です。それで、次のジレンマが現れました...ドメインモデルに大きな穴を開けずにそれを表現する方法は？
制約を格納するために追加のアプリケーション層オブジェクトを導入するのは簡単ですが、「許可された/必要なプロパティ」はビジネス上の問題であり、ドメインユーザー（ある種のマネージャー）がそれを変更できるようにする必要があるため、このロジックをドメイン層。
どんな提案でも大歓迎です。
編集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マッピングが複雑になり、パフォーマンスが低下しますが、すべてのドメインロジックがドメインオブジェクトに保持されます。
改善、提案、意見は大歓迎です。