Только агрегат root имеет доступ к хранилищу
Означает ли это, что у меня не может быть отдельной таблицы / коллекции базы данных для отдельного хранения электронных писем? Это означает, что электронные письма должны быть встроены в пользовательский документ.
Это означает, что должна быть установлена единая блокировка, если вы собираетесь внести какие-либо изменения в любой из элементов-участников агрегата. , Это, безусловно, означает, что представление данных агрегата хранится в одной базе данных; но вы, конечно, могли бы распределить информацию по нескольким таблицам в этой базе данных.
Еще в 2003 году использование реляционных баз данных в качестве книги записей было обычным явлением; отношения один ко многим обычно включают несколько таблиц в одной базе данных.
Объекты вне агрегата могут получать доступ только к другим объектам в агрегате через агрегат root.
Я не могу напрямую иметь конечную точку API, такую как / users / {userId} / emails и обрабатывать ее напрямую в EmailService.getEmailsByUserId (String userId)?
Конечно, вы можете; вы сделаете это, сначала загрузив сущность root совокупности пользователей, а затем вызвав методы для этой сущности, чтобы получить необходимую вам информацию.
Перспектива: Эванс выступал против идеи что приложение должно иметь возможность напрямую манипулировать произвольными объектами в доменной модели. Вместо этого приложение должно быть разрешено только сущностям "root" в модели домена. Фактически, это ограничение означает, что приложению на самом деле не нужно понимать ограничения, которые разделяются несколькими сущностями.
Через четыре или пять лет появилась cqrs , что еще больше уточнить эту идею - оказывается, что в случаях использования только для чтения модель предметной области не обязательно вносит большой вклад; вам не нужно беспокоиться об инвариантах, если они уже выполнены, и вы ничего не меняете.
Фактически это означает, что GET /users/{userId}/emails может просто извлекать данные из представления, доступного только для чтения, без необходимости вообще задействовать модель предметной области. Но POST /users/{userId}/emails необходимо продемонстрировать первоначальный подход (то есть нам нужно изменить данные с помощью модели предметной области)
означает ли это, что мне нужно сначала go в UserRepo и вытащить пользователь, а затем вытащить электронные письма, я не могу просто сделать EmailService, напрямую разговаривающего с почтовым репо
В оригинальном тексте Эванса репозитории предоставляют доступ к root сущностям , а не произвольные объекты. Так что, если «электронная почта» является сущностью в «совокупности пользователей», то обычно у нее не будет собственного репозитория.
Кроме того, если вы столкнетесь с этой идеей, это может быть «Запах кода» пытается заставить вас осознать, что ваши совокупные границы находятся не в том месте. Если электронная почта и пользователь находятся в разных агрегатах, то для курса вы будете использовать разные репозитории, чтобы получить к ним доступ.
Хитрость заключается в том, чтобы признать, что совокупный дизайн является отражением того, как мы блокируем нашу данные для модификации, а не то, как мы связываем наши данные для отчетности.