Как отделить домен ядра данных от домена REST?

Question

Мне интересно, что является предпочтительным способом отделить объект основного домена от объекта, обслуживаемого уровнем REST.

Я увидел на этом просветительском учебнике весны REST http://spring.io/guides/tutorials/rest/1/, что хорошо не подвергать модель основного домена непосредственно на уровне REST, поскольку она должна развиваться независимо от модели основного домена.

Основная услуга - обработка и производство событий. Эти события рассматриваются как коммуникационные порты приложения. Основная служба не видит объект домена REST. И контроллер REST не видит какой-либо объект основного домена.

Чтобы упростить задачу, рассмотрим пример только одного объекта - объекта Order.

В руководстве показано, как класс домена REST домена передается запросом REST контроллеру. В свою очередь, контроллер создает объект OrderDetails, переданный в событие обработки заказа, для создания события CreateOrderEvent, которое затем передается службе, которая возвращает другое событие OrderCreatedEvent. Контроллер, наконец, создает объект заказа домена REST из возвращаемого события и отправляет его в ответ.

Мы можем видеть, что для этого одного объекта существует один класс для объекта основного домена, один класс для объекта домена REST и один класс для объекта полезной нагрузки события.

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

Любые мысли об этом дизайне или альтернативном дизайне? Есть ли какой-либо предпочтительный способ достижения этой развязки?

Спасибо за любое предложение.

С наилучшими пожеланиями,

Stephane

Еще один вопрос теперь у меня есть ...

Должен ли я пойти на исключение объект NotFoundException или для члена notFoundEntity событий в случае, на REST домен, выделенный из домена данных?

Событие, отправленное обратно на контроллер, может нести состояние члена notFoundEntity, которое может использоваться в контроллере.

Вот notFoundEntity событие логика:

protected boolean notFoundEntity = false; 

public boolean isNotFoundEntity() { 
    return notFoundEntity; 
} 

public static OneAdminEvent notFound(Long id) { 
    OneAdminEvent oneAdmiEvent = new OneAdminEvent(id); 
    oneAdmiEvent.notFoundEntity = true; 
    return oneAdmiEvent; 
} 

служба обновляет состояние участника событий в зависимости от сущности того, были найдены или нет:

Admin admin = adminRepository.findOne(deleteAdminEvent.getId());    
if (admin == null) { 
    return AdminDeletedEvent.notFound(deleteAdminEvent.getId()); 

В контроллере, вызов проверки для лица, которое было найдено или нет:

if (adminDeletedEvent.isNotFoundEntity()) { 
} 

Это соответствует развязывающий дизайн.

Но, я не уверен, что событие развязки должно содержать эту информацию.Эту информацию можно рассматривать как исключение, исключение для бизнеса.

Кроме того, с помощью исключения позволяет указать атрибут отката в транзакционной аннотации:

@Transactional(rollbackFor = NotFoundException.class) 

С исключением, только не найдено объектом логика слева на службе, это событие не содержит Любые.

Служба теперь выглядит следующим образом:

Admin admin = adminRepository.findOne(deleteAdminEvent.getId());    
if (admin == null) { 
    throw new NotFoundException("No admin was found with the id " + deleteAdminEvent.getId()); 

Что эмпирическое правило использовать, чтобы решить, когда использовать государство-член в случае и когда использовать бизнес пользовательское исключение?

Answer 1

Было бы труднее, если бы в этом примере приложение еще больше отделяло уровни домена домена REST и ядра. Объекты REST (a.k.a. «view») не только были отделены от объектов ядра (a.k.a. «domain»), но их прямая связь также была отключена с помощью внутренней управляемой событиями архитектуры. Причина, по которой основные события напоминают вам так сильно о методах HTTP, скорее всего, объясняется простотой примеров использования примера, чем необходимостью или дизайном. Таков пример опасности. :)

Хотя это, безусловно, звуковой способ сложить приложение, реальный вопрос в том, нужен ли он для вашего конкретного сценария. Если ваше приложение будет очень ориентировано на данные (например, система ввода данных с несколькими бизнес-правилами), вам может не понадобиться отдельный набор объектов домена REST (так как вы можете решить, что вам не нужен отдельный слой " просмотреть "объекты в традиционном приложении MVC). Вы можете использовать подход Spring Data REST (см. Пример приложения RESTBucks Оливера Гирке). Опять же, если у вас есть тяжелая бизнес-логика в основном и вы хотите создать богатую модель домена, вам, вероятно, будет лучше с более развязанной архитектурой.