DDD: Где разместить логику сохранения и когда использовать сопоставление ORM
Мы долго и внимательно изучаем шаблоны наших (Java) веб-приложений. В прошлом мы страдали от чрезмерно анемичной объектной модели и чрезмерно процедурного разделения между контроллерами, службами и DAO, когда между ними перемещались простые объекты-значения (в основном просто пакеты данных). Мы использовали декларативную (XML) управляемую ORM (Hibernate) для сохранения. Все управление сущностями происходило в DAO.
Пытаясь перейти к более богатой модели предметной области, мы сталкиваемся с трудностями, как лучше спроектировать уровень сохраняемости. Я потратил много времени на чтение и размышления о шаблонах доменного дизайна. Однако мне нужен совет.
Во-первых, вещи, в которых я более уверен:
У нас будут «тонкие» контроллеры на переднем плане, которые имеют дело только с HTTP и HTML - формами обработки, проверкой, логикой пользовательского интерфейса.
Мы будем есть уровень сервисов бизнес-логики без сохранения состояния, которые реализуют общие алгоритмы или логику, не осведомленные о пользовательском интерфейсе, но очень хорошо осведомленные (и делегирующие) модель предметной области.
У нас будет более богатая модель предметной области, которая содержит состояние, отношения , и логика, присущая объектам в этой модели предметной области.
Вопрос возникает вокруг настойчивости. Раньше наши сервисы внедрялись (через Spring) с DAO и использовали методы DAO, такие как find () и save () для обеспечения сохраняемости. Однако более богатая модель предметной области, по-видимому, подразумевает, что объекты должны знать, как сохранять и удалять себя, и, возможно, службы более высокого уровня должны знать, как находить (запрашивать) объекты домена.
Здесь возникает несколько вопросов и неопределенностей:
Хотим ли мы внедрить DAO в объекты домена, чтобы они могли "это сделать" .someDao.save (this) "в методе save ()? Это немного неудобно, поскольку объекты домена не являются одиночными объектами, поэтому нам понадобятся фабрики или пост-конструирующая настройка DAO. При загрузке сущностей из базы данных это становится беспорядочным. Я знаю, что для этого можно использовать Spring AOP, но мне не удалось заставить его работать (используя платформу Play !, еще одну линию экспериментов), и это кажется довольно беспорядочным и волшебным.
Мы вместо этого сохраняем DAO (репозитории?) полностью отдельно, наравне со службами бизнес-логики без сохранения состояния? Это может иметь некоторый смысл, но это означает, что если «сохранить» или «удалить» являются неотъемлемыми операциями объекта домена, объект домена не может их выразить.
Мы просто полностью откажемся от DAO и используем JPA, чтобы позволить сущностям управлять собой.
В этом заключается следующая тонкость: довольно удобно отображать сущности, использующие JPA. Игра! framework также предоставляет нам хороший базовый класс сущностей с такими операциями, как save () и delete (). Однако это означает, что сущности нашей модели предметной области довольно тесно связаны со структурой базы данных, и мы передаем объекты с большим объемом логики сохранения, возможно, вплоть до уровня представления. По крайней мере, это сделает модель предметной области менее пригодной для повторного использования в других контекстах.
Если мы хотим избежать этого, нам понадобится какое-то отображение DAO - либо с использованием простого JDBC (или, по крайней мере, Spring JdbcTemplate) , или используя параллельную иерархию сущностей базы данных и «бизнес-сущностей», при этом DAO постоянно копируют информацию из одной иерархии в другую.
Какой здесь правильный выбор дизайна?
Мартин