Следует ли мне вводить что-то в свои сущности?

Это Загадка электронных таблиц: вы пишете repository.store (объект) или entity.storeIn (репозиторий)?

У каждого есть свои достоинства. Обычно я предпочитаю repository.store (entity) по той причине, что я сохраняю методы своих сущностей сфокусированными на предметной области. Имеет смысл написать pen.dispenseInkOnto (Surface), потому что это то, что делают ручки. Немного меньше смысла писать pen.storeIn (penRepository).

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

Что касается общей инъекции классов, в примере pen.dispenseInkOnto (Surface) вы вполне можете сделать Surface интерфейсом и использовать инъекцию. Я не вижу в этом проблем, пока вы вводите другие сущности, объекты значений или службы.

Абсолютно. Вот как вы не привязываете класс к какой-то конкретной реализации сохраняемости. Иногда я пишу имитирующие классы DAO, которые «сохраняются» только в структурах памяти, и внедряю их при модульном тестировании.

Я бы вообще не рекомендовал этого.

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

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

Вообще я не советую. Сущности - это всего лишь сущности, которые должны представлять некоторую идентифицируемую и важную часть вашего основного домена. У них должна быть одна обязанность, и они должны быть очень, очень хороши в этом. Если объекту требуются дополнительные услуги для выполнения задачи (например, для сохранения самого себя), вы начинаете позволять таким вещам, как инфраструктура, проникать в ваш домен. Даже идея о том, что счет-фактура может рассчитать его фактурную стоимость, не обязательно является обязанностью класса Invoice. Это может потребовать таких вещей, как налог с продаж, стоимость доставки, скидки для клиентов. Как только вы откроете эти двери и попытаетесь начать вносить эти элементы в свой счет-фактуру, он станет классом для всего. Доменные службы лучше подходят для координации организаций и предоставления им услуг. Инфраструктурные сервисы лучше подходят для таких вещей, как постоянство и внешние коммуникации. Оба они подходят для внедрения других сервисов через IoC (и поощряются, чтобы они сами не становились раздутыми программами).

Я тоже не советую этого делать, но рекомендую прочитать Форум DDD, так как там есть много сообщений об этом. Сомнительно, стоит ли вам вообще внедрять в доменные службы, в более сложных доменах, я думаю, нет.

Как сказал Бил, сервисы отлично подходят для кросс-агрегированной координации и особенно для любой координации с чем-либо за пределами домена.