The Infamous Entity Framework - Aggregate Root Issue

Question

I have stumbled through StackOverflow and Google and other sites but could not grasp the concept of how to implement it.

Here I have a very very simple model: An Item and an ItemActivity. It is clear that the Item is the aggregate root and the ItemActivity is an entity.

So according to DDD principles I should only implement ItemRepository. Besides its own -lets say- CRUD operations the ItemRepository should also manage its child entity's, ItemActivity's, CRUD operations too.

And here comes some implementation issues:

1. Should I implement child entity operations in the domain or repository.
2. Loading all child entities related to an item or navigating to them is OK with Entity Framework. Loading the root with .include(..) will do the work. But what about updading an ItemActivity or even deleting an ItemActivity? Removing them from the collection does not persist.
3. Assume that I have to find all activities within a time span. How can such a query be implemented while I cannot query over ItemActivity or worse there does not exist any ItemActivityRepository at all.
4. Is there a sample covering this topic. There are a lot of articles written about it, many answers without concrete code and theoretical coverages but please, are there any real samples. I have worked on Microsoft Spain N-Layered DDD Sample but it is not detailed enough.

Best regards.

Answer 1

1.Should I implement child entity operations in the domain or repository.

No. the repository manipulates the aggregate only.

2.Loading all child entities related to an item or navigating to them is OK with Entity Framework. Loading the root with .include(..) will do the work. But what about updading an ItemActivity or even deleting an ItemActivity? Removing them from the collection does not persist.

  Item.getActivity().updateRemark("...");
  ItemRepository.store(Item);

3.Assume that I have to find all activities within a time span.

You'd better make ItemActivity another aggregate root if you need to query them by range. Smaller aggregates helps this case.

4.Is there a sample covering this topic.

The famous Effective Aggregate Design. There is some sample code(especially in Part 1) relates to your case closely.