在 JavaEE 中创建具有适当分层的 Web 服务

Question

我正在使用 Java EE 来运行我的后端系统，我有一个关于如何在创建 Web 服务方面适当分层的问题。

我几乎按照 DDD 的原则来组织我的应用程序，这意味着我有一个域层、存储库层和一个服务层。所以服务层用@Stateless注解，它们是我的EJB。

现在，我可以发疯了，用更多的 JAX-RS 框架注释来注释这个服务类......但我不知道这是否正确，原因如下：

1. 这不会有点混合层次感吗？
2. 我怎样才能对我的 Web 服务进行版本控制？假设我今天创建了一个 web 服务，明天我发现它真的很糟糕，但是在晚上有人创建了一个使用它的应用程序，如果我将其丢弃，应用程序将无法再使用。我想要的是可以在 www.myurl.com/api/v1/customers 上找到的网络服务 以及 www.myurl.com/api/v2/a_new_customers_webservice 上的新网络服务

这就是我想要的。

可能还有其他缺点吗？

那么解决方案是什么？如果我说我创建了另一组使用 JAX-RS 注释进行注释的类，然后这些方法可以在内部使用来自服务层中 EJB 的方法，我是否正确？

如果有另一个 Web 服务版本，我可以创建另一组使用其他 URL 和逻辑的类。还是我都错了？你会如何组织这个？

Answer 1

根本问题是如何组织代码以供重用。正如您所指出的，您可以：

1. 使用 JAX-RS 注释您的 EJB 服务以使其成为 Web 服务；
2. 创建重用其他常见 EJB 服务（一级间接）的 EJB Web 服务（即使用 JAX-RS 注释）；
3. 创建将公共逻辑重用为 POJO（一级间接）的 EJB Web 服务。

这三个对我来说都是有效的选择。

如果您对 EJB 服务的 API 有信心，但对 Web 服务的 API 没有信心（可能存在阻抗不匹配），我会选择 2。

如果您对 EJB 服务应该做什么没有信心，那么这可能是首先要弄清楚的事情；）

如果您现在有信心，但怀疑它将来可能会改变，我现在会选择最简单的解决方案 1，然后根据必须更改的内容在必要时进行重构。申请YAGNI。