Re: Avoid injecting Service/Repository in an Entity

Maybe an EnrollmentSpecification? Students must satisfy this specification
in order to be added to a class.This specification would use a repository
to find the answer. As stated in earlier comments, you don't want to pull
every student from the database, but remember that repositories can also
have methods that compute counts, or give yes or no answers, in this case
maybe isStudentEligibleForEnrollment method in your repository would help.


On Tue, Mar 25, 2014 at 8:15 PM, Brian Sayatovic <[email protected]> wrote:

>
>
> Sounds like Enrollment itself could  be an entity. Would that make things
> easier?
> On Mar 25, 2014 1:03 PM, <[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
>>
>> }
>>
>> }
>>
>>
>>
>>
>>    
>