Specification Pattern with Navigation Properties

Question

Is it correct to use Specification Pattern with Navigation Properties ?

I have the follow context:

When I add a student, I need to validate the addresses.

Student class:

public class Student {
    public string Name { get; set; }
    public DateTime Birth { get; set; } 
    //...
    public virtual ICollection<StudentAddress> StudentAdresses { get; set; }
}

StudentAddress class:

public class StudentAdress{
    public int Id { get; set;}
    public string Street { get; set; }
    //...
}

On my student service (DDD):

Service:

public void AddStudent(Student student)
{
    // code
    var studentValidation = new StudentValidation().Validate(student); // Student Validation has a set of specifications that will populate a validation result object and that I'll retrieve it by Domain Controller Notification (MVC)
   // code
}

PS: Student Validation has a set of specifications that will populate a validation result object and that I'll retrieve it by Domain Controller Notification (MVC)

Back to the question...

Where may I put my Student Addresses class specifications ?

I thought of the possibility of putting them inside StudentValidation class and there use the Navigation property to be able to validate each address. I do not know if that is correct. It would be a type of transversal validation.

Why is StudentAddress an entity? It should be a value object. — Constantin Galbenu, Mar 18 '17 at 12:44
I think my answer to this question may guide you in the right direction regarding UI validations vs domain validations: http://stackoverflow.com/questions/28395176/should-i-abstract-the-validation-framework-from-domain-layer/28397201#28397201 — plalx, Mar 18 '17 at 15:10
Constantin, StudentAddress is a table on my DB. It has identity and I think that Value Objects are a set of properties of a specific Entity. — Wilson Santos, Mar 18 '17 at 17:51

score 0 · Answer 1 · answered Oct 27 '17 at 18:43

In DDD, validation is a form of ensuring invariants are met. This is the responsibility of the Aggregate Root in an Aggregate. In your example, perhaps Student is the root of the Student Aggregate, with StudentAddress as a child. In that case, it makes sense for Student to be responsible for ensuring the aggregate is in a valid state. Ideally, the logic for this should literally live inside of the Student class itself, but in your case you appear to be using a StudentService to perform validation of Student. So, in your case, it would be fine and proper (IMO) to perform the address validation from StudentService, since it's essentially taking on the responsibility of your aggregate root.

Whether or not you need separate validator types for StudentAddress than for Student depends on the context/scope of the validation rule in question. For example, if you must validate that an Address includes a City, that's easily done at the StudentAddress level. However, if you need to validate that a Student has at least one Address, or that a Student doesn't have two duplicate Addresses, that would need to be done at the Student level.

You can learn more about DDD in general here.

Specification Pattern with Navigation Properties

1 Answers1