Доменное программирование с использованием Spring

У меня вопрос по DDD и Spring. Я всегда разрабатываю свое приложение на основе анемичной модели предметной области и сервиса, заботясь о бизнес-логике / постоянстве.

Предположим, у вас есть Spring управляемая служба сохранения / репозитория для объекта домена, например. Книга. Если мне нужно предоставить метод save () в книге, мне понадобится компонент репозитория внутри моего домена, или мне придется искать контекст для компонента репозитория. Что прямо противоположно внедрению зависимостей.

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

Возможно, я ошибаюсь, но если кто-нибудь может объяснить мне, как этот сценарий будет работать, это будет большим подспорьем.


spring design-patterns pojo domain-driven-design
person Jany    schedule 24.02.2011    source источник
comment
Репозитории традиционно являются частью домена, верно? По крайней мере, если мы принимаем инструкции из книги Domain Driven Design как традиционные.   -  person TM.    schedule 25.02.2011
comment
Даже в этом случае репозиториями управляет Spring, как мы внедряем эти репозитории, не нарушая концепцию DI.   -  person Jany    schedule 25.02.2011

Ответы (2)


arrow_upward
2
arrow_downward

Я думаю, что «фасад» вашего приложения должен использовать репозиторий (или другой сервис инфраструктуры) для сохранения «книги». Книга не должна сохранять себя, это ответственность Репозитория.

Если вам нужно выполнить какую-либо операцию инфраструктуры (например, выполнить поиск в базе данных) из объекта домена, вы должны получить доступ к этому репозиторию, просмотрев контекст (и в результате подключившись к Spring) или внедрив репозиторий через Dependency Инъекция в сущность.

Проблема в том, что за «создание экземпляра» Entity отвечает не Spring, а поставщик сохраняемости, поэтому Spring не может справиться с этой инъекцией. Что делать?

Что ж, есть несколько способов (ни один из них не очень "красивый") сделать это:

  • Через АОП: вы можете инструментировать код с помощью Aspect Oriented Framework (например, AspectJ), настраивая систему для внедрения любой зависимости в Entity в момент создания экземпляра.
  • Через перехватчик Hibernate: если ваш Persistence Provider находится в Hibernate, он предлагает вам ловушку для размещения перехватчиков в определенных точках жизненного цикла сущностей. Вы можете настроить перехватчик, который ищет контекст Spring для внедрения зависимостей в экземпляр каждой сущности.
  • Возможно, самый простой способ - реализовать небольшой статический "serviceLocator" в сочетании с spring, который ищет службы, запрашиваемые объектами, когда они им нужны. Этот локатор сервисов - всего лишь слой, позволяющий избежать привязки ваших сущностей к Spring.
person Mr.Eddart    schedule 28.06.2011

arrow_upward
1
arrow_downward

Я думаю, что метод "сохранения" (например, сохранение в БД) не принадлежит объекту домена ... Книга "сохраняет" себя? Или репозиторий его сохраняет? ...

person eolith    schedule 25.02.2011
comment
+1 операции сохранения / обновления / удаления ... не принадлежат самому объекту домена. - person fmucar; 25.02.2011
comment
Метод сохранения принадлежит объекту домена, который является делегированием сохранения в репозиторий. если сохранение перемещено в службу репозитория, тогда уровень бизнеса / обслуживания вызовет репозиторий, чтобы сохранить домен, который обращается к многоуровневой архитектуре служб. Думаю, мне придется начать читать о DDD, чтобы понять мои концепции - person Jany; 25.02.2011