Почему методы репозитория должны принимать доменную сущность в качестве параметра?

Question

Предположим, у нас есть отдельные модели чтения, поэтому мы используем репозитории только на стороне записи, а не на стороне чтения. (и этот вопрос все о стороне записи)

Также давайте предположим, что одной из наших целей является полная инкапсуляция агрегатов / сущностей таким образом, чтобы они отражали только поведение, а не состояние. (имеется в виду, нет получателей / установщиков)

Далее, давайте предположим, что мы не хотим использовать ORM или рефлексию для получения агрегированных внутренних компонентов из репозитория.

Очевидно, что одно из оставшихся решений состоит в том, что агрегат сам выставляет свое полное состояние как VO / POCO и передает его в хранилище. Затем хранилище будет знать, как сопоставить его с DAO и сохранить его.

Теперь, во многих местах я читал, что репозитории должны принимать агрегаты сами.

Вопрос: почему? Что плохого в том, что агрегат выставляет VO своего состояния, передает его в репозиторий и позволяет репо делать сохранение на его основе?

Преимущество - полная и чистая инкапсуляция агрегатов.

Answer 1

Что плохого в том, что агрегат выставляет VO своего состояния, передает его в хранилище и позволяет репо делать сохранение на его основе?

Этот подход нарушает некоторые другие предположения идеи моделирования предметной области.

Одно из таких предположений заключается в том, что ключевая бизнес-логика и «сантехника» должны быть отделены друг от друга. Тот факт, что вам нужно получить сериализуемое представление агрегата, является случайностью того факта, что вы пытаетесь записать состояние в стабильное хранилище (этот шаг был бы совершенно ненужным, если бы вы хранили агрегат в кэше в памяти).

Второе предположение заключается в том, что использование «объектов» для моделирования домена - хорошая идея. Если бы вы использовали функциональный подход, то, конечно, вы бы сохраняли значения, а не объекты.

Мне кажется, это помогает помнить, что контекст решений, которые мы пишем, сильно изменился за последние 15-20 лет. Шаблоны, которые имеют смысл для локализованного приложения с длинными сеансами, включающими много взаимодействий, не обязательно имеют смысл для распределенных приложений без сохранения состояния, и наоборот.

этот паттерн заставляет вас жертвовать совокупной инкапсуляцией

Нет, это не так - запрос объекта для копии некоторой информации в ранее согласованном представлении не нарушает инкапсуляцию. См., Например, Кевлин Хенни .

Однако для этого требуются интерфейсы, подходящие для двух разных соавторов: ваших приложений, которые заботятся о бизнес-правилах, и вашего хранилища, которое заботится о сохранении представлений.