Должны ли объекты домена иметь вложенные в них зависимости?

Я специально говорю об этом вопросе: DDD - Как реализовать заводы

Выбранный ответ заявил:

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

Мой вопрос: какова причина того, что вы не можете вводить зависимости в свои сущности? Или я просто неправильно понимаю это выражение? Может кто-то прояснить?

Ответ 1

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

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

Factory - это шаблон для выделения логики построения объектов. Это также хорошая практика, которую DDD рекомендует, но не очень нужен во всех сценариях.

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

Ответ 2

Вид старого, но я действительно хочу обратиться к этому, потому что я много работал с этим и высказываю свое мнение по этому поводу:

Я часто слышу, что объекты домена не должны "зависеть" от вещей. И это правда. Я часто вижу, что люди экстраполируют это, чтобы не вводить вещи в объект домена.

Это противоположность зависимости. Домен не должен зависеть от других проектов, это верно. Но домен может определять свои собственные интерфейсы, которые затем могут реализовать другие проекты, которые затем могут быть добавлены обратно в домен. Как мы все знаем, это то, что называется инверсией зависимостей (DI).

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

Мне действительно кажется, что я, должно быть, сумасшедший здесь, потому что я чувствую, что все читают "Домен не должен иметь никаких зависимостей", тогда он думает, что "что-то вводит что-то, значит, вы зависите от него", и приходит к выводу: поэтому мы не можем вводить зависимости в область.

Это оставляет нам замечательную логику:

Инверсия зависимостей == Зависимость