問題

私は、一連のルールに基づいて更新する必要があるフィールドを持つ単純なEntity Frameworkバックアップドメインオブジェクトを持つシステムを設計しています。これらのルールを徐々に(アジャイルスタイルで)実装したいのですが、EFを使用しているので、各ルールをドメインオブジェクトに入れることについては不思議です。しかし、私は "手続き型コード"とanemicドメインモデルを使

例として、オブジェクトは次のとおりです。

 class Employee { 
 private string Name; 
 private float Salary; 
 private float PensionPot;
 private bool _pension;
 private bool _eligibleForPension;

}
 

私は "Salaryが100,000以上で_eligibleForcentoryがfalseの場合、set_eligibleForCentoryをtrueとして設定する"というルールを構築する必要があります。

約20のルールがあり、EmployeeRulesクラスで実装する必要があるかどうか、またはEmployeRulesクラスのようなアドバイスを探していますか?私の最初の考えは、 "Rule"から継承する各ルールごとに別々のクラスを作成し、Employeeクラスに各ルールを適用することでした。おそらくVisitorパターンを使用していますが、すべてのフィールドをルールに公開して間違っていると感じます。 Employe

2番目の懸念事項は、実際の従業員がDBにバックアップされたEntity Frameworkエンティティであるため、これらの「エンティティ」にロジックを追加することができないということです。特に、各ルールを単体テストするためにオブジェクトをモックする必要があるときです。同じオブジェクトでテストしているルールがある場合、どうすれ

私はルールを適用する前に簡単なドメインオブジェクトに変換するためにAutoMapperを使用することを考えていましたが、自分でフィールドへの更新を管理する必要があります。これに関するアドバイス?

  ベストアンサー

1つのアプローチは、ルールをEmployeeの内部クラスにすることです。このアプローチの利点は、フィールドがプライベートであることです。また、ルールの呼び出しは、Employeeクラス自体によって強制され、必要に応じて常に呼び出されるようにすることができます。

 class Employee
{
    string id;
    string name;
    float salary;
    float pensionPot;
    bool pension;
    bool eligibleForPension;

    public void ChangeSalary(float salary)
    {
        this.salary = salary;
        ApplyRules();
    }

    public void MakeEligibleForPension()
    {
        this.eligibleForPension = true;
        ApplyRules(); // may or may not be needed
    }

    void ApplyRules()
    {
        rules.ForEach(rule => rule.Apply(this));
    }

    readonly static List<IEmployeeRule> rules;

    static Employee()
    {
        rules = new List<IEmployeeRule>
        {
            new SalaryBasedPensionEligibilityRule()
        };
    }

    interface IEmployeeRule
    {
        void Apply(Employee employee);
    }

    class SalaryBasedPensionEligibilityRule : IEmployeeRule
    {
        public void Apply(Employee employee)
        {
            if (employee.salary > 100000 && !employee.eligibleForPension)
            {
                employee.MakeEligibleForPension();
            }
        }
    }
}
 

ここでの1つの問題は、Employeeクラスにすべてのルール実装が含まれていなければならないことです。これは、従業員の年金に関連するビジネスロジックを具体化するルールなので、大きな問題ではありません。