Позволяет ли DDD объединить корневой список?

Question

Я пытаюсь понять основы доменного дизайна.Вчера я нашел некоторый код в проекте, с которым я работаю, когда репозиторий возвратил список сущностей, то есть List getMessages (), где Message является сущностью (имеет собственный идентификатор и может быть изменен).Теперь, читая о репозиториях в DDD, они довольно точно указывают, что репозиторий должен возвращать корень агрегирования, и что любые действия с агрегатом должны выполняться с помощью вызова методов в корне агрегирования.Список в своем собственном классе, а затем просто вернуть этот класс.Но в моем проекте в принципе нет необходимости делать это, за исключением соответствия с DDD, поскольку мы только показываем сообщения, добавляем новые или удаляем существующее сообщение.Нам никогда не придется удалять все сообщения, поэтому единственными методами, которые у нас есть, являются addMessage(...), getMessages(), updateMessage(...) и removeMessage(...), что в основном и делает наша доменная служба.

Любойидеи кто-нибудь?Какова наилучшая практика в DDD для описания агрегатов и репозиториев?

Answer 1

Одним из запутанных аспектов новичков в DDD является концепция хранилища. Repository: Посредничает между доменом и слоями отображения данных, используя подобный коллекции интерфейс для доступа к объектам домена.

Репозиторий предоставляет возможность получить ссылку на Совокупный корень. Не Entity, Value Object, но Aggregate root (я не согласен с «Репозитарий должен вернуть Aggregate Root»).

Предложения: - Один репозиторий на один совокупный корень

• Интерфейсы репозитория (например, IMessageRepository) находятся в доменной модели

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

• Реализации репозитория (например, NHibernateMessageRepository, если используется nhibernate) находятся за пределами домена

Надеюсь, это поможет !!