Устранение проблем с производительностью с ассоциациями DDD

Question

Я знаю, что этот вопрос был рассмотрен несколько раз, но я не могу найти ответ, который наилучшим образом соответствует моему сценарию.

В настоящее время я борется за создание ассоциаций между сущностями в подходе DDD, имея представление в виду. Предположим, что мы имеем объект en Article с атрибутом Author как атрибут. Этот же Author имеет объект Mail как атрибут, который в моем проекте является объектом значения (он может быть регулярным атрибутом, но это только для примера). Оба объекта Article и Author являются AR.

Скажем, я хочу отобразить список статей для данного автора. Для каждой статьи я хочу только отображать имя автора в каком-то заголовке. На данный момент, допустим, у меня есть метод «findByAuthor», реализованный в ArticleRepository.

Этот метод при вызове возвращает список объектов Article со своим соответствующим объектом Author. Этого было бы достаточно, поскольку мне нужно только имя автора, который является простым атрибутом объекта Author. Мне не нужен объект Mail.

В простом приложении с небольшим учетом производительности это было бы полностью нормально, но давайте представим, что мой домен находится на удаленном приложении, доступном через REST API. Транспортировка списка AR со всеми их ассоциациями кажется огромным производителем, когда мне нужна небольшая часть этих ассоциаций.

Как я могу решить эту проблему без рассмотрения обходных решений, таких как lazy-loading?

Answer 1

Вы можете (и должны) использовать CQRS для таких проблем. Я бы просто создал еще один совокупный корневой объект, называемый AuthorArticles и репозиторий для него (каждый AR нуждается в отдельном репозитории).

authorArticles = authorArticlesRepository.getByAuthorId(authorId) 

и authorArticles в JSON будет выглядеть так:

{ 
    "authorName": "Foo", 
    "articles": [ 
     { 
       "title": "Bar", 
       "text": "Lorem ipsum dolor" 
     }, 
     { 
       "title": "Xyz", 
       "text": "Lorem ipsum dolor" 
     } 
    ] 
} 

Очень важно, чтобы вы положили в статьи объектов только те данные, которые вам нужны. Если вам не нужен глобальный идентификатор статьи для этой модели запроса, не помещайте ее туда.