ДДД. Должен ли я изменить сущность внутри репозитория?

У меня есть вопрос о реализации шаблона DDD и репозитория. Должен ли я изменить сущность внутри репозитория?

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

    1. 
var order _orderRepository.GetById(1);
order.Finish();
_orderRepository.Update(order);

...где изменение сохраняется в базе данных при вызове Update.

2.

var order _orderRepository.GetById(1);
var finishedOrder = _orderRepository.Finish(order);

...где изменение сохраняется в базе данных при вызове Finish.

Есть ли преимущество использования одного метода над другим? Каков DDD-способ сделать это?


repository-pattern domain-driven-design ddd-repositories repository-design
person Erik Z    schedule 22.01.2016    source источник
comment
Первый путь правильный.   -  person Jehof    schedule 22.01.2016
comment
@Jehof Я тоже так думаю, но почему я должен предпочесть первое другому?   -  person Erik Z    schedule 22.01.2016
comment
Потому что я думаю, что не репозиторий несет ответственность за пометку заказа как выполненного. Это зависит от команды (при использовании CQRS) или службы домена.   -  person Jehof    schedule 22.01.2016

Ответы (2)


arrow_upward
5
arrow_downward

Вы не должны изменять его в репозитории.

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

Если вы также сделаете его ответственным за некоторую бизнес-логику, вы нарушите принцип единой ответственности.

Если вы проводите автоматизированное тестирование, это также означает, что вам нужно выполнить интеграционные тесты, чтобы убедиться, что связь/отображение базы данных работает, а затем модульные тесты для проверки введенной вами бизнес-логики.

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

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

person jgauffin    schedule 22.01.2016

arrow_upward
0
arrow_downward

Используйте прикладной уровень для координации поведения одного или нескольких объектов домена, объекты домена должны выполнять все изменения состояния, и, наконец, репозиторий должен сохранять эти изменения в базе данных или там, где вы храните состояние домена.

person Venture    schedule 06.02.2016