c# - 貧血ドメインからドメインドリブンへ

Question

貧血ドメインが実際に何を意味するかについて、明確で単純な例を見つけようとしていました. 周りにはたくさんの理論があり、よく答えられた質問もたくさんあります。それでも、「貧血ドメイン」の意味が実際にどの程度まで進んでいるかについては、明確なイメージを得ることができませんでした. したがって、貧血ドメイン設計のダミーの実用的な例を見て、これをドメイン駆動型の設計にどのように進化させることができるかを尋ねるよりも簡単だと思います...

では、タイプTaskDataのデータ エンティティがあるとします。

public class TaskData
{
    public Guid InternalId { get; set; }

    public string Title { get; set; }

    public string Details { get; set; }

    public TaskState ExplicitState { get; set; }

    public IEnumerable<TaskData> InnerTasks { get; set; }

}

また、計算された状態である「 ActualState 」と呼ばれる追加のプロパティが必要です。タスクに内部サブタスクがある場合、値は子に厳密に依存します。それ以外の場合、「ActualState 」は「 ExplicitState」と等しくなります。

このロジックを別のサービスクラス (「エンジン」と呼びます) に記述すると、次のようになります。

internal class TaskStateCalculator
{
    public TaskState GetState(TaskData taskData)
    {
        if (taskData.InnerTasks.Any())
        {
            if (taskData.InnerTasks.All(x => this.GetState(x) == TaskState.Done))
            {
                return TaskState.Done;
            }
            if (taskData.InnerTasks.Any(x => this.GetState(x) == TaskState.InProgress))
            {
                return TaskState.InProgress;
            }

            return TaskState.Default;
        }

        return taskData.ExplicitState;
    }       
}

最初の質問は次のとおりです。

上記のコードは、 TaskStateCalculatorサービス/エンジンがドメイン レイヤーの一部であっても、貧弱なドメイン設計を反映していますか? はいの場合、それを回避するために、ロジックをTaskDataクラス内に移動する必要があります (そして、TaskDataをTaskに名前変更します)。私は正しいですか？

2番目の質問は（実際にはそれらのチェーンです）：

もっと困難な状況になったらどうしますか？Taskエンティティ内にComputeSomethingというプロパティが必要であり、このプロパティのロジックが Task のリポジトリ全体にアクセスする必要があるとします。この場合、TaskクラスはTaskRepositoryに依存します。これでよろしいでしょうか？EF はそのようなクラスのインスタンスをどのように構築しますか? 代替手段は何ですか？