Should I avoid using aggregate roots?

Question

PROBLEM

There are four entities:

class Product : Entity<Product> {
    public virtual String Title { get; set; }
    public virtual Category Category { get; set; }
    public virtual Vendor Vendor { get; set; }
}

class Category : Entity<Category> { /* properties */ }
class Vendor : Entity<Vendor> { /* properties */ }

Neither of these four are defined as components and I don't know which one should I use (mark it with IAggregateRoot interface) as an aggregate root.

I need to easily access lists of vendors , categories to show them on a page while creating a new product.

Then it appears there should be three Repository instances as per these entities.

ASIDE

I've seen several largescale projects. They massively use lists of independent entities like Vendor, State, TechnicalOptions. I think it is logical to design things with aggregate roots but I don't know whether DDD principles are suitable there.

Answer 1

They look like different aggregates and it can be confirmed by applying the rule of cascading delete :

The rule of Cascading Delete is sometimes cited as a good way to tell if you have a group of Entities or VOs that should be an Aggregate – if the parent was deleted all other parts of that Aggregate below would be deleted too. So if it doesn't make sense that a parent being deleted would also delete all children, then you don't have an Aggregate, you just have a good old fashioned reference.

In your case, given a Product if this get deleted you don't want cascading delete all the related categories as they may be related to other Products(you can apply this rules to the other Entities). So you will probably have one repository for each of them

Answer 2

You should not have one AR reference an instance of another. Rather reference by ID or use a Value Object.

Then try not to query your domain model as this leads to some lazy-lading and other nasty designs. Rather create a thin query layer to return the data you need. You may even want to denormalize some of the data for the query layer to improve performance.