1

次の機能の実装をより適切に整理する方法について質問があります。ユーザーが一意の電子メールとパスワードを使用してシステムに登録する必要があり(最初のステップ)、次に登録を確認する必要があるとします (2 番目のステップ) 。アプリケーション サービス/ドメイン サービス/ユーザーエンティティ間の最初のステップ (登録) の構造化実装にはいくつかの選択肢があり、どれが優れているかわかりません。

最初のオプション:

AppService:

var existingUser = UserRepository.GetUserByEmail(email);

if (existingUser != null)
{
    throw new ValidationException(...);
}

var newUser = UserFactory.CreateUser();

newUser.Register(email, password);

UserRepository.Save(newUser);

// commit

したがって、ここではドメイン サービスは使用しません。私が個人的に不便に感じているのは、電子メールの一意性ビジネス ルールがアプリケーション サービスでチェックされることです。これはビジネス ルールです。

2 番目のオプション:

AppService:

var user = UserRegistrationDomainService.RegisterUser(email, password);

UserRepository.Save(user);

// commit

UserRegistrationDomainService:

User RegisterUser(email, password)
{
  var existingUser = UserRepository.GetUserByEmail(email);

  if (existingUser != null)
  {
    throw new ValidationException(...);
  }

  var newUser = UserFactory.CreateUser();

  newUser.Register(email, password);

  return newUser;

}

ここで気に入らないのは、このソリューションが、リポジトリからユーザーを取得して User.ConfirmRegistration() を呼び出すだけの 2 番目のステップの実装と完全に対称的でないことです。そのため、登録確認にはドメイン サービスは必要ありませんが、登録には 2 番目のオプションでそのようなサービスを使用します。

どちらのオプションが優れていますか? 最初のオプションのアプリケーション サービスに電子メールの一意性検証を含めることはできますか?

4

2 に答える 2

1

オプション 1 は、固有の電子メール ルールがアプリケーション固有であることを意味します。つまり、ドメイン dll (または jar、モジュールなど) を別のアプリケーションで再利用する場合、ルールは存在しなくなります。

そのルールはアプリケーションにとらわれないと合理的に考えることができるので、私はオプション 2 を選択します。

別の解決策は、代わりに Factory に実装することです。結局のところ、これは通常、ユーザーの作成時に検証ロジック (null/空の名前のチェック、電子メール形式の検証など) を配置する場所なので、すべての作成ルールを同じ場所に集中させてみませんか?

于 2012-05-30T12:15:58.260 に答える