[salex89]

Actually, very similar, since Entity Framework is usually used. Sources implement the IQueriable interface which lets you write queries with method chaining or LINQ. To be honest, it kinda looks better than it is. In reality I find it produces sub-optimum performance and a lot of things can not be done without spilling query logic to the app. Not to mention a lot of linq/method chaining queries cannot be translated to SQL (by the database provider).

[UK-AL]

You can persist this model using anything you want.

You would have some kind adapter/library that handles the persistence.

It would take these models, and covert them into your datastore.

[TekMol]

How would that work in practice? Would this line stay the same:

    RegisteredCourses.Add(course);

And magically trigger an insert in the database?

[UK-AL]

The repository pattern in the original example would allow you serailise your objects to whatever datastore you want. His object design isn't that great for being persistence ignorant though. I would instead do something like this.

    Course - Aggregate Root

    Student - Aggregate Root
        RegisteredCourse[] - RegisteredCourses - An array objects with date time of registration, and id reference to course.

The method for adding a course would simply create a new RegisteredCourse and place it in the registered courses array.

_studentRepository.save(student) would be a simple matter converting this in memory representation into sql.

I'm not big fan of using lazy loading, and direct references to other aggregates inside of other aggregates. This makes mapping these models without ORM difficult.

[TekMol]

Can you show in real code, what you mean? From the text you wrote, I cannot grok it.