2

一般に、(コンストラクターまたはセッターを介して) エンティティーにサービスを注入し、エンティティーにそれへの参照を保持させることは悪い習慣と見なされていることを私は知っています。

しかし、メソッドを呼び出すときに Service をエンティティに一時的に渡すことは問題ないでしょうか?

たとえばname、エンティティのフィールドをバージョン管理し、呼び出されるVersionServiceたびに新しいバージョンを作成したい場合、次のsetName()ようにできます。

public class Entity
{
    public void setName(String name, VersionService service)
    {
        this.name = name;
        service.addVersion(this, name);
    }
}

このコードで私が気に入っているのは、setName()を提供しないとメソッドを呼び出すことができないためVersionService、目的の動作が強制されることです。をモックすることで、簡単にテストすることもできVersionServiceます。

Jimmy Bogardによるダブル ディスパッチ パターンに関する投稿で、このアプローチの例を見つけました。

しかし、スタックに関するいくつかの議論から、一般的なコンセンサスは、ドメイン モデルのサービスへの依存を避けることであると考えました。

この件について何か考えはありますか？

4

3 に答える 3

2

しかし、スタックに関するいくつかの議論から、一般的なコンセンサスは、ドメイン モデルのサービスへの依存を避けることであると考えました。

ドメインサービスに関する限り、それらをエンティティで使用することに反対する議論を知りたいです。ドメイン サービスは、ユビキタス言語に含まれるファースト クラスのドメイン オブジェクトです。別のエンティティを呼び出すのと同じように、エンティティに配置されたロジックがドメイン サービスに配置されたロジックを呼び出すことが正当化されるシナリオはたくさんあります。

この記事のパラグラフ 3 には、この良い例があります。

于 2012-11-16T13:40:13.550 に答える
1

通常、ドメインイベントを使用して、新しいバージョンを生成します。

public class Entity
{
    public void setName(String name)
    {
        this.name = name;
        DomainEvent.Publish(new MyEntityGotRenamed(Id));
    }
}

public class YourService : ISubscribeOn<MyEntityGotRenamed>
{
     public void Handle(MyEntityGotRenamed domainEvent)
     {
         var entity = repos.Get(domainEvent.Id);
         AddVersion(entity);
     }
}

イベントをサブスクライブする方法は、プラットフォームによって異なります。

setNameこれはドメインアクションを表すものではないことに注意してください。Renameクライアントが定義したものである必要があります。

于 2012-11-16T10:09:32.070 に答える
1

ドメイン イベント アプローチは優れていますが、メッセージ ドリブン アーキテクチャの使用に依存しています。

それにもかかわらず、具体的にはあなたが与えた例では、サービスを使用して他のモデルを更新することはエンティティの問題ではないため、サービスを引数として渡しません。エンティティ (おそらく集約ルート) は、独自のモデルのみを扱います。エンティティを呼び出すコードは、サービスも呼び出すことができます。

ただし、他の必要なデータを取得するために、サービスを引数として渡すことは問題ないと思います (残念ながら、今は例が思いつきません)。ただし、ほとんどの場合、サービスをコンストラクターの依存関係として渡します。つまり、そのサービスは操作以上に必要であり、データをメソッド引数として提供することはできません。

于 2012-11-17T16:05:20.243 に答える