8

私は DDD を学んでおり、次の基本的な質問があります。

ファクトリ、豊富なドメイン モデル、リポジトリでは、(CRUD の) 作成、読み取り、更新が処理されるようですが、削除はどうでしょうか? エンティティの削除に関するいくつかのビジネス ロジックがある可能性があります。どこでそれを処理しますか? RepositoryImpl (インフラストラクチャに属する) レイヤーは、それらの不変条件をチェックすること自体を気にする必要はありません。その仕事は、基になるデータストアから特定のエンティティを削除することです。これは工場の意図とは正反対のようですが、DDD には工場を削除するための "kill" のようなものはありません。

ユーザーが削除できる Order エンティティがあるとしますが、それが「履行済み」状態になるまで削除できないため、削除を要求するクライアントrepo.delete(ent)は例外を受け取る必要があります。同様に、クライアントが削除を要求したときに更新が行われるシナリオが存在する可能性があります (ステータスの変更またはソフト削除フラグの設定など)。

このようなシナリオはどこで処理する必要がありentity.delete()ますか (それは理にかなっていますか?)、または削除と呼ばれるアプリケーションまたはドメイン サービスで処理します。私が心配しているのは、Repository インターフェイスに delete というメソッドがある限り、どのクライアントもサービス メソッドをバイパスして repo メソッドを直接呼び出すことができるということです。

コンテキストを追加するだけで、レイヤーをどのように構築するかはJavaパッケージを介して行われ、パッケージの可視性をツールとして使用して、レイヤー間の相互作用の破損を禁止します。

4

1 に答える 1

7

私の知る限り、DDD の削除に関する具体的なガイドラインはありません (「削除」は非常に一般的でデータ指向の用語です)。これは「エンド オブ ライフ」と呼ばれ、リポジトリの責任です。ほとんどの場合、サポート終了は単純ではなく、いくつかのビジネス ルール、おそらく状態の変更などに関連しています。非常に多くの場合、ドメイン オブジェクトはまったく削除されず、「アーカイブ済み」状態に移行するだけです。Udi Dahan によるこの記事を読むことを強くお勧めします。

オブジェクトの寿命に関連する不変条件を強制するために、次のようにコードを構成できます。

class Order{
  ...
  bool CanBeArchived(){
    ...
  }
  ...
}

interface OrderArchiver {
  // throws InvalidOperationException if order can not be archived
  void Archive(Order order);
}

class NHibernateOrderArchiver implements OrderArchiver {      
  void Archive(Order order){
    if(!order.CanBeArchived()){
      throw new InvalidOperationException("Order can not be archived.");
    }
    ...
  }
}

メソッド「CanBeArchived」は、実装が注文に関連付けられた他のドメイン オブジェクトへのアクセスを必要とする場合、「OrderArchiver」インターフェイスの一部にすることもできます。

于 2012-08-02T16:21:03.267 に答える