DDD Agregate, Entity, Repository понятным языком?

Question

[magary4]

давно курю тему ДДД
и постоянно запутываюсь

как эти 3 понятия взаимодействуют?

Answer 1

[Dmitry MiksIr]

Entity - сущность бизнеса. То, что еще называют "моделью", хотя этот термин так засрали, что лучше и не вспоминать про него. С чем работает наша проблемная область? С Клиентом, с менеджером, с заказов, с товаром - это и будут сущности. Важный момент - у сущности есть уникальный идентификатор.

Репозиторий - это коллекция сущностей, паттерн по управлению сущностями. Из репозитория мы их получаем, в репозиторий отправляем. Конкретная реализация репозитория на persistence уровне уже занимается сохранением и поиском сущностей в базах данных.

С аггрегатом и просто и сложно. Когда мы проектируем нашу предментую область, мы можем выделить такие сущности, которые не должны использоваться в отрыве от какой-то другой. Например, есть сущности "конкурс" и "фото на конкурс". Последняя не может существовать без конкурса, не может использоваться без него. При этом, именно "конкурс" мы будем спрашивать - сколько фото пришло. Удаляя конкурс - нужно удалить все фото этого конкурса. В таких случаях, мы определяем сводные (aggregate) границы и выделяем главную сущность (aggregate root или сводный корень). Ссылаться "извне", т.е. из других сущностей, не входящий в аггрегат мы можем только на сводный корень. Запрашивать из репозитория можем только сводный корень. И т.п., там много ограничений. Основная идея тут - инкапсулировать взаимодействие связанных сущностей внутри сводных границ, упростив таким образом глобальные взаимодействия.

Comments

[magary4]

да спасибо. проясняется

Скажите
вод допустим у меня в проекте есть вот это solarium.readthedocs.io/en/stable/getting-started

эта библиотека уровень инфраструктуры?
откуда я должен обращаться к ней?
// create a client instance
$client = new Solarium\Client($config);
// get an update query instance
$update = $client->createUpdate();
такой код должен быть в репозитории???

результатом этого всего являеться инстанс Solarium\Query\Result\Document
репозиторий после его получения должен преобразовать его в агрегат и вернуть его?

[Dmitry MiksIr]

Ваша доменная сущность не обязательно должна совпадать с объектами, возвращаемыми библиотеками работы с базами данных. Document - это не доменная сущность. https://github.com/leopro/trip-planner смотрели как пример DDD? Вот сущности https://github.com/leopro/trip-planner/tree/master..., вот интерфейс репозитория https://github.com/leopro/trip-planner/blob/master... Вот реализация https://github.com/leopro/trip-planner/blob/master...

В реализации репозитория вы работаете с Solr, извлекаете что нужно, и на основе полученных данных - создаете нужные доменные сущности.

[magary4]

>> доменная сущность не обязательно должна совпадать с объектами, возвращаемыми библиотеками работы с базами данных

ну так я так и написал - репозиторий обращаеться к библиотеке и получает Solarium\Query\Result\Document который преоразует возвращают доменную сущьность Order к примеру

[Dmitry MiksIr]

Ну да, именно так. Даже когда работают с доктриной и другими ORM - часто не используют сущности ORM напрямую как доменные сущности, а делают "конвертацию".

В DDD главное - проектирование домена. Обычный подход, когда пишется домен без написания инфраструктуры. И когда уже готовы основные сущности, их взаимодействие, интерфейсы репозиториев, написаны сервисы - тогда можно приступать к написанию реализации репозиториев.