Does DDD allow for a List to be an Aggregate Root?

Question

I am trying to understand the fundamentals of Domain-driven design. Yesterday I found some code in a project I am working with where a Repository returned a list of Entities, i.e. List getMessages() where Message is an entity (has its own id and is modifiable). Now, when reading about Repositories in DDD they are pretty specific that the Repository should return the Aggregate Root, and that any actions on the aggregate should be done by invoking methods in the Aggregate Root.

I would like to place the List in its own class and then just return that class. But, in my project there is basically no need to do that except for compliance with DDD, since we only show messages, add new ones or remove an existing message. We will never have to remove all messages, so the only methods we would have are, addMessage(...), getMessages(), updateMessage(...) and removeMessage(...) which is basically what our Domain Service is doing.

Any ideas anyone? What is the best practice in DDD when it comes to describe Aggregates and Repositories?

Answer 1

One of the confusing aspects of those new to DDD is repository concept. Repository: Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects.

A Repository provides the ability to obtain a reference to an Aggregate root. Not Entity, Value Object, but Aggregate root ( i dont agree with "Repository should return the Aggregate Root").

Suggestions: - One repository per aggregate root

• Repository interfaces (e.g. IMessageRepository) reside in the domain model

public interface IMessageRepository()
{
     void saveMessage(Message msg);
     void removeMessage(Message msg);
     Ilist<Messages> getMessages();
}

• Repository implementations (e.g. NHibernateMessageRepository if using nhibernate) reside outside the domain

Hope this help!!