私は現在、最終段階のプロジェクトのコードをいくつかリファクタリングしていますが、多くのビジネス ロジックをドメイン オブジェクトではなくサービス クラスに配置することになりました。この時点で、ほとんどのドメイン オブジェクトはデータ コンテナーのみです。私は、ほとんどのビジネス ロジックをサービス オブジェクトで記述し、後ですべてをリファクタリングして、より再利用可能で読みやすい形にすることにしました。そうすれば、どのコードをドメイン オブジェクトに配置するか、どのコードを独自の新しいオブジェクトに分割するか、どのコードをサービス クラスに残すかを決定できました。だから私はいくつかのコードを持っています:
public decimal CaculateBatchTotal(VendorApplicationBatch batch)
{
IList<VendorApplication> applications = AppRepo.GetByBatchId(batch.Id);
if (applications == null || applications.Count == 0)
throw new ArgumentException("There were no applications for this batch, that shouldn't be possible");
decimal total = 0m;
foreach (VendorApplication app in applications)
total += app.Amount;
return total;
}
このコードは、ドメイン オブジェクト自体が唯一の入力パラメーターであるため、ドメイン オブジェクトに追加するのに適しているようです。いくつかのリファクタリングの完璧な候補のようです。しかし、唯一の問題は、このオブジェクトが別のオブジェクトのリポジトリを呼び出すことです。そのため、サービスクラスに残しておきたいと思います。
したがって、私の質問は次のとおりです。
- このコードをどこに配置しますか?
- この機能を分解しますか?
- 厳密なドメイン駆動設計に従っている人は、それをどこに置きますか?
- なんで?
御時間ありがとうございます。
編集注:これにはORMを使用できないため、遅延読み込みソリューションは使用できません。
編集注2:データレイヤーがリフレクションを使用してドメインオブジェクトをインスタンス化する方法のため、コンストラクターを変更してパラメーターを取り込むことはできません(私の考えではありません)。
編集注3:バッチオブジェクトがアプリケーションのリストを合計できるとは思いません。その特定のバッチにあるアプリケーションのみを合計できるように思われます。それ以外の場合は、関数をサービス クラスに残す方が理にかなっています。