2
ビジネスロジックをサービスレイヤーに移動せずに、ドメインオブジェクト属性の一意の制約を確認するための洗練された方法はありますか？
私はドメイン駆動設計を約8年間適応してきましたが、これらすべての年が経過した後でも、まだ1つ問題があります。それは、ドメインオブジェクトに対してデータストレージ内の一意のレコードをチェックしています。 2013年9月、Martin Fowlerは、可能であればすべてのドメインオブジェクトに適用する必要があるTellDon'tAsk原則について言及し、操作がどのように行われたかをメッセージで返します（オブジェクト指向の設計では、これはほとんど例外によって行われます）。操作は失敗しました）。 私のプロジェクトは通常多くの部分に分かれており、そのうちの2つはドメイン（ビジネスルールのみを含み、ドメインは完全に永続性を無視する）とサービスです。データをCRUDするために使用されるリポジトリレイヤーを認識するサービス。 オブジェクトに属している属性の一意性はドメイン/ビジネスルールであるため、ドメインモジュールにとっては長くなければならないため、ルールは本来あるべき場所にあります。 レコードの一意性を確認できるようにするには、現在のデータセット（通常はデータベース）にクエリを実行して、別のレコードNameが存在するかどうかを確認する必要があります。 ドメインレイヤーは永続性を無視しており、データを取得する方法がわからないだけでなく、データを操作する方法しか考慮していないため、リポジトリ自体に直接触れることはできません。 私が適応させたデザインは次のようになります。 class ProductRepository { // throws Repository.RecordNotFoundException public Product GetBySKU(string sku); } class ProductCrudService { private ProductRepository pr; public ProductCrudService(ProductRepository repository) { pr = repository; } public void SaveProduct(Domain.Product product) { try { pr.GetBySKU(product.SKU); throw Service.ProductWithSKUAlreadyExistsException("msg"); } catch (Repository.RecordNotFoundException e) { // suppress/log …