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

Question

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

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

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

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

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

Мы можем видеть, что для этого одного объекта существует один класс для объекта основного домена, один класс для объекта домена 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 (он же "вид") были четко отделены от базовых (то есть "домен") объектов, но их прямая связь также была отделена через внутреннюю архитектуру, управляемую событиями. Причина, по которой основные события так сильно напоминают вам HTTP-методы, вероятно, больше связана с простотой примеров использования примера, чем с необходимостью или замыслом. Такой может быть опасность примера.:)

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