rest - 如何将数据核心域与 REST 域解耦？

Question

我很好奇将核心域实体与 REST 层所服务的实体分离的首选方法是什么。

我在这个启发性的 Spring REST 教程中看到了 http://spring.io/guides/tutorials/rest/1/最好不要在 REST 层中直接公开核心域模型，因为它应该独立于核心域模型而发展。

核心服务是处理和产生事件。这些事件被视为应用程序的通信端口。核心服务看不到任何 REST 域实体。 REST Controller 看不到任何核心域实体。

为了让事情更简单，让我们考虑一个只有一个实体的例子，Order 实体。

本教程展示了 Order REST 域类如何通过 REST 请求传递到 Controller 。反过来， Controller 创建一个 OrderDetails 实体，传递给 Order 处理事件以创建 CreateOrderEvent 事件，然后将其传递给返回另一个 OrderCreatedEvent 事件的服务。 Controller 最终根据返回的事件创建一个 REST 域 Order 实体，并在响应中发送它。

我们可以看到，对于这一实体，核心域实体有一个类，REST 域实体有一个类，事件负载实体有一个类。

此外，我们可以看到位于应用程序核心中的事件扩展了一些基本事件，这些事件强烈地提醒了 HTTP 方法。当我们首先尝试做的是将应用程序核心与 REST 层解耦时，看到这种 REST 之类的东西渗入应用程序核心，这有点令人惊讶。

对这种设计或某种替代设计有什么想法吗？是否有任何首选方法可以实现这种解耦？

感谢您的任何建议。

亲切的问候，

斯蒂芬

我现在还有一个问题……

在与数据域分离的 REST 域上，我应该选择实体 NotFoundException 异常还是事件中的 notFoundEntity 事件成员？

发送回 Controller 的事件可以携带一个 notFoundEntity 成员状态，可以在 Controller 中使用。

这是事件 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());

在 Controller 中，调用检查实体是否已找到:

if (adminDeletedEvent.isNotFoundEntity()) {
}

这符合解耦设计。

但是，我不确定解耦事件是否应该携带此信息。这个信息可以看作是一个异常，一个业务自定义异常。

此外，使用异常可以在事务注释中指定回滚属性:

@Transactional(rollbackFor = NotFoundException.class)

除了一个异常(exception)，剩下的唯一未找到的实体逻辑是在服务上，事件不包含任何。

该服务现在看起来像:

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(又名“ View ”)对象与核心(又名“域”)对象完全分离，而且它们的直接通信也通过内部事件驱动架构分离。核心事件如此强烈地提醒您 HTTP 方法的原因可能更多是由于示例用例的简单性，而不是必要性或设计。这可能是榜样的危险。 :)

虽然这当然是对应用程序分层的一种合理方式，但真正的问题是它是否对您的特定场景有必要。如果您的应用程序将非常面向数据(例如，具有很少业务规则的数据输入系统)，您可能不需要一组单独的 REST 域对象(就像您可能决定不需要单独的“查看”传统 MVC 应用程序中的对象)。您可以采用 Spring Data REST 方法(请参阅 Oliver Gierke 的 RESTBucks 示例应用程序)。再说一次，如果您在核心中有一些繁重的业务逻辑并且想要创建一个丰富的域模型，那么使用更加解耦的架构可能会更好。