Avoid injecting Service/Repository in an Entity

I think proper DDD would imply encapsulating transaction boundaries in
aggregates. So if your business rule needs be to the millisecond
consistent, that would mean having something like a SurnameClassEnrollment
aggregate. This class would maintain a list of registrations during
specific periods for a given surname. The class would have a
RegisterForClass(classId, from, to) method, which does something like your
AddStudent method.

-Freek



On Tuesday, March 25, 2014,
<[email protected]<javascript:_e(%7B%7D,'cvml','[email protected]');>>
wrote:

>
>
> Hi Everyone,
>
> From what I've read, this is really bad. But I have the following use case
> so wondering how to do this in the proper DDD way. The business rule is
> contrived but it is very similar to what i have in real life. I just cannot
> disclose the use case due to NDAs.
>
> I have a class named Class. A class can have students in it. There is a
> business rule such that if a student with the same surname belongs to any
> current of any other class, they cannot be added to the class.
>
> So on Class, i have a method named AddStudent. Just wondering how would
> the algorithm be implemented in a proper DDD sense
>
> public class Class
> {
>
> public void AddStudent(Student student)
> {
>
> // Call a repository to get all the students enrolled in all classes
> // If any students surname matches the surname of the student passed in,
> do not thing
> // otherwise add the student
>
> }
>
> }
>
>
>
>
>  
>