Должен ли я вводить вещи в мои сущности?

Question

При использовании контейнера IoC считается ли целесообразным вводить в них другие классы? то есть класс постоянства

Answer 1

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

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

Answer 2

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

Answer 3

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

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

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

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

Answer 4

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

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

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

Answer 5

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