Являются ли аннотации настойчивости в объектах домена плохой практикой?

Я понимаю, что основы персистентности, такие как Morphia и Hibernate, полагаются на аннотации на объекты домена, чтобы сделать свою магию. На каком-то уровне мне кажется, что это вставляет проблемы сохранения в доменный уровень, чего мы должны стремиться избегать.

Это что-то, что я должен попытаться уклониться, возможно, используя внешний файл конфигурации или, возможно, отдельные DTO из модели домена? Или это небольшая утечка между уровнями персистентности и домена, которые обычно считаются приемлемыми?

Ответ 1

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

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

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

Hibernate аннотации на объекты домена? Это прекрасный компромисс между простотой внедрения и простотой обслуживания на мой взгляд.

Ответ 2

Являются ли аннотации сохранения в объектах домена плохой практикой?

Да. С возникновением NoSQL вы не можете полагаться на единую стратегию сохранения.

Например, сегодня я сохраняю свои объекты домена (допустим, используя морфию) в MongoDB. Что делать, если завтра я хочу сохранить объекты домена Neo4j?

Или, возможно, вы захотите сохранить объекты домена для всех трех типов баз данных, таких как реляционные (Postgres/MySQL), MongoDB (хранилище документов) и Neo4J (база данных графа) только для оценки.

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

Лучшая практика. Прохождение Постоянная стратегия как шаблон стратегии может помочь. Но будьте осторожны при разработке ваших классов/объектов.

Ответ 3

Недавно я работал над достаточно сложной системой, имеющей отдельный слой сохранения, и это была огромная боль в заднице и очень плохо для ремонтопригодности. Вы в основном рассматриваете конфликт между принципами YAGNI и Single Responsibility. На мой взгляд, YAGNI является более важным (увы, также более часто игнорируется).

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

Чтобы быть уверенным: всегда делайте фактический материал настойчивости (вызывая функции ORM) на отдельном уровне службы /DAO! Таким образом, легче ввести слой persistence позже, если вы обнаружите, что вам это нужно.

Ответ 4

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

Ответ 5

Короткий ответ: мне нравятся постоянные, богатые объекты домена.

Длинный ответ:

В течение почти 10 лет я работал над довольно большой системой ~ 500K LOC, используя Spring и Hibernate. Сначала мы начали с подхода "транзакция script" (см. Fowler), отчасти потому, что мы не доверяли Hibernate. Однако за короткое время мы стали доверять Hibernate, и благодаря моему гораздо более раннему обучению в довольно пуристском OO, я стал большим сторонником переходной настойчивости в сочетании с подходом, основанным на управлении доменами. Мы в основном пришли к мысли о том, что наша система поддерживается ODBMS (с большим количеством небольших утечек: -)).

Я назвал нашу архитектуру "ядром домена", потому что книга DDD еще не была написана. Это было в первые дни Hibernate, поэтому модель домена не была загрязнена аннотациями. Отдельная забота о сохранении сохранялась отдельно в XML-сопоставлениях.

Снова, со временем, нам стало лучше продвигать поведение в доменном слое. У нас была довольно традиционная схема контроллера → service → dao → , которая была применена с учетом времени компиляции. То, что я наблюдал с течением времени, заключается в том, что эта модель очень хорошо работала для нашей системы, которая представляла каждый аспект довольно сложной области управления планом 401 (k), включая настройку плана, торговлю, учет, тестирование соответствия, продажи, брендинг и т.д. Богатая модель домена с (относительно) прозрачной "магической" настойчивостью была ключом к тому, что мы могли создавать новые функции с точки зрения существующих функций в модели домена.

Наш сервисный уровень только организовал взаимодействие между техническими службами (такими как электронная почта, ввод-вывод файлов, очередь и т.д.) и помог охватить пакеты доменов, когда это необходимо. Уровень обслуживания также определяет границу транзакции (через Spring). Услуги только получили или выпустили DTO или примитивы. Многие люди ненавидят это, как перерыв в DRY, но мы обнаружили, что это помогло нам честно определить интерфейсы службы и код, который их использовал. Это также упростило отдаленные вещи позже.

Этот подход позволил нам создать высококачественное программное обеспечение с довольно небольшой командой (мы были командой Scrum).

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

Ответ 6

Я полагаю, что буду использовать аннотации в своем домене, если я уже решил использовать структуру персистентности, которую я собираюсь использовать, однако XML будет более удобным, если вы последуете за Hexagonal и TDD. Если вы аннотируете свой домен с определенной структурой, вы будете связаны с интеграцией настойчивости и не сможете протестировать основные функции с целью стать агностиком технологии/структуры.

Ответ 7

Я бы предпочел объекты с богатым доменом, на которых есть аннотации. Даже Эванс использует этот подход в своем образце приложения. Он использует XMl вместо Annotations, но он все еще сохраняет те же объекты.

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