1

ドメイン駆動設計の文献では、ドメイン サービスはステートレスであるべきだとよく言われます。

これは、サービス コールが単一の作業単位を表す必要があるためだと思います。複数のサービス メソッドが使用するサービス状態があってはなりません。

サービスに必要なすべての関連リポジトリをコンストラクターで挿入できるように、サービス アーキテクチャでこの規則を破ります。例：

public class UserService : IUserService
{
    public IUnitOfWork UnitOfWork { get; set; }

    public IUserRepository UserRepository { get; set; }

    public ICustomerRepository CustomerRepository { get; set; }

    public UserService(IUnitOfWork unitOfWork, IUserRepository userRepository, ICustomerRepository customerRepository)
    {
        UnitOfWork = unitOfWork;
        UserRepository = userRepository;
        CustomerRepository = customerRepository;
    }

    public User RegisterNewUser(...)
    {
        // Perform relevant domain logic
    }

    // ...
}

でコンストラクター注入を使用するにはUserService、サービス メソッドが関連するリポジトリなどにアクセスできるように、状態 (プロパティ) が必要です。

個々のサービス メソッドを独立した作業単位として設計したいと考えていますが、必ずしもそれを防ぐことはできません。

ステートレスになるようにドメイン サービスを構築するにはどうすればよいでしょうか。 これも必要ですか？

編集：

Eric EvansのDomain-driven Design: Tackling Complexity in the Heart of Software :

ドメイン内の重要なプロセスまたは変換が ENTITY または VALUE OBJECT の自然な責任ではない場合、サービスとして宣言されたスタンドアロン インターフェイスとしてモデルに操作を追加します。モデルの言語に関してインターフェースを定義し、操作名が UBIQUITOUS LANGUAGE の一部であることを確認します。SERVICE を ステートレスにします。

また、 Vaughn Vernonは著書「Implementing Domain Driven Design 」でステートレス サービスを推奨しています。

4

2 に答える 2

0

目標に近づく 1 つの方法は、IOC コンテナーをサービス クラスに挿入し、プロパティの get メソッドをオーバーライドして、必要なクラスのインスタンスを解決することです。新しいクラスは次のようになります。

public class UserService : IUserService
{
  private IUnitOfWork UnitOfWork 
  { 
    get{return container.Resolve<IUnitOfWork>()}
  }
  private IUnityContainer container {get;set;}

  public UserService(IUnityContainer container )
  {
    this.container = container;
  }

  public User RegisterNewUser(User user)
  {
     //Domain logic
  }

}

サービス クラスが IOC コンテナーに依存するようになりましたが、これは良いことではありませんが、ステートレス サービスに近づこうとしている場合は、これで十分です。

于 2014-02-26T14:44:11.143 に答える